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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Smart Card Platform (SCP). 

The contents of the present document are subject to continuing work within TC SCP and may change following formal 
TC SCP approval. If TC SCP modifies the contents of the present document, it will then be republished by ETSI with 
an identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

early working draft; 

1 presented to TC SCP for information; 

2 presented to TC SCP for approval; 

3 or greater indicates TC SCP approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 

The present document is part 1 of a multi-part deliverable covering the Test specification for the Single Wire 
Protocol (SWP) interface, as identified below: 

Part 1 : " Terminal features ' ' ; 

Part 2: "UICC features". 



Introduction 

The present document defines test cases for the terminal relating to Single Wire Protocol (SWP). SWP is the 
communication interface between the UICC and a contactless frontend (CLE) as specified in TS 102 613 [1]. 

The aim of the present document is to ensure interoperability between the terminal and the UICC independently of the 
respective manufacturer, card issuer or operator. 
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Scope 



The present document covers the minimum characteristics which are considered necessary for the terminal in order to 
provide compliance to TS 102 613 [1]. 

The present document specifies the test cases for: 

• the physical layer of the interface CLF - UICC; 

• the electrical interface of the CLF; 

• the initial communication establishment CLF - UICC; 

• the data hnk layer. 

Test cases for the UICC relating to TS 102 613 [1] and test cases for the host controller interface (HCI) covering both 
terminal and UICC are out of scope of this document. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

• In the case of a reference to a TC SCP document, a non specific reference implicitly refers to the latest version 
of that document in the same Release as the present document. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were vahd at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 102 613: "Smart Cards; UICC - Contactless Front-end (CLF) Interface; Part 1: Physical 

and data link layer characteristics". 

[2] ETSI TS 102 221: "Smart Cards; UICC-Terminal interface; Physical and logical characteristics". 

[3] ETSI TS 102 600: "Smart Cards; UICC-Terminal interface; Characteristics of the USB interface". 

[4] ETSI TS 102 622: "Smart Cards; UICC - Contactless Front-end (CLF) Interface; Host Controller 

Interface (HCI)". 

[5] ISO/lEC 14443-3: "Identification cards — Contactless integrated circuit cards — Proximity cards — 

Part 3: Initiahzation and anticollision" . 

[6] ISO/lEC 14443-4: "Identification cards — Contactless integrated circuit cards — Proximity cards — 

Part 4: Transmission protocol". 

[7] ISO/lEC 9646-7: "Information technology — Open Systems Interconnection — Conformance 

testing methodology and framework — Part 7: Implementation Conformance Statements". 

[8] ISO/lEC 18092: "Information technology — Telecommunications and information exchange 

between systems — Near Field Communication — Interface and Protocol (NFCIP-1)". 
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[9] ISO/IEC 13239: "Information technology — Telecommunications and information exchange 

between systems — High-level data link control (HDLC) procedures". 

[10] ISO/lEC 14443-2: "Identification cards — Contactless integrated circuit cards — Proximity cards — 

Part 2: Radio frequency power and signal interface". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

Not appUcable. 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions apply given in TS 102 613 [1] and the following 
apply: 

corrupted frame: SWP frame which is well-formed with respect to the MAC layer, with the exception that the CRC16 
in the frame does not match with the CRC16 result calculated over the payload 

NOTE: This frame has at least 1 byte payload. Used by the TE to represent the situation where the DUT receives 
a corrupted frame (unless otherwise specified). 

nomenclature used for tests involving SHDLC LLC: 

For SHDLC link establishment, following definitions apply: 

• ES transmits RSET: 

RSET(): RSET fi-ame without payload. 

RSET(Ws=w): RSET frame with one byte payload. 

RSET(Ws=w, SREJ=S): RSET frame with two bytes payload. For the endpoint capabilities byte, 
SREJ=0 represents the value 0x00, SREJ=1 represents the value 0x01. 

• ES receives RSET: 

RSET: RSET frame with any valid payload. 

RSET(): RSET fi-ame without payload. 

RSET(Ws=w): RSET frame with one byte payload. 

RSET(Ws=w, SREJ=S): RSET frame with two bytes payload. For the endpoint capabilities byte, 
SREJ=0 represents the value 0x00, SREJ=1 represents the value 0x01. 

For every calculation on NSO_T, NSO_S or NR in the test procedures use modulo 8. 

non-occurrence RQ: RQ which has been extracted from TS 102 613 [1], but which indicates a situation which should 
never occur 

NOTE: The consequence is that such RQs can not be explicitly tested. 
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representative SWP frame exchange procedure: sequence of SWP frames exchanged between TE and DUT 

NOTE: Used by the TE to cause SWP communication traffic where needed in test procedures. This sequence 
shall provide the following characteristics, unless otherwise specified or more precisely stated in test 
procedures: 

Amount of data exchanged between TE and DUT at least 500 byte (with respect to the MAC layer), 
valid for both directions. 

Some half-duplex SWP communication. 

Some full-duplex SWP communication. 

Frame transmission started by the TE while the DUT yet sends a frame. 

Exchanged data shall enforce occurrence of some bit stuffing in both directions. 

Some variation of frame length sent from the TE. 

The DUT provider shall provide sufficient information to allow this procedure to be defined. 

representative USB frame exchange procedure: sequence of USB frames exchanged between TE and DUT 

NOTE: Used by the TE to cause USB communication traffic where needed in test procedures. 

user: describes any logical or physical entity which controls the test equipment in a way that it is able to trigger 
activities of the DUT 



3.2 Symbols 



For the purposes of the present document, the symbols given in TS 102 613 [1] and the following apply: 
The characters x, y, z represent any values for the current test, unless otherwise specified 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in TS 102 613 [1] and the following apply: 

(U)SIM Universal Subscriber Identity Module 

ACT ACTivation protocol 

CLE ContactLess Frontend 

CLT ContactLess Tunnelling 

CRC Cyclic Redundancy Code 

DUT Device under test 

ES SHDLC endpoint of test equipment (i.e. the UICC simulator) 

FES For further study 

ESC Frame Size for proximity Card 

HCI Host Controller Interface 

HCP Host Controller Protocol 

LLC Logical Link Control 

NAA Network Access Application 

NR Number of next information frame to Receive 

NS Number of next information frame to Send 

PCD Proximity Coupling Device 

RQ Conformance requirement 

SHDLC Simplified High Level Data Link Control 

SWIO Single Wire protocol Input/Output 

SWP Single Wire Protocol 

T Terminal, i.e. the DUT (shortcut used only in test procedure tables) 

TE Test equipment 

WS Window Size 
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3.4 



Formats 



3.4.1 Format of the table of optional features 

The columns in table 4. 1 have the following meaning: 



Column 


Meaning 


Option: 


The optional feature supported or not by the implementation. 


Status: 


See clause 3.4.3 'Status and Notations' 


Support: 


The support columns are to be filled in by the supplier of the implementation. The following common 
notations, defined in ISO/IEC 9646-7 [7], are used for the support column in table 4.1 . 
Y or y supported by the implementation. 
N or n not supported by the implementation. 

N/A, n/a or - no answer required (allowed only if the status Is N/A, directly or after evaluation of a 
conditional status). 


Mnemonic: 


The mnemonic column contains mnemonic identifiers for each item. 



3.4.2 Format of the applicability table 

The applicability of every test in table 4.2 a) is formally expressed by the use of Boolean expression defined in the 
following clause. 

The columns in table 4.2 have the following meaning: 



Column 


Meaning 


Test case: 


The "Test case" column gives a reference to the test case number(s) detailed in the present document 
and required to validate the implementation of the corresponding item in the "Description" column 


Description: 


In the "Description" column a short non-exhaustive description of the requirement is found. 


Release: 


The "Release" column gives the Release applicable and onwards, for the item in the "Description" 
column 


Execution 
requirements 


The usage of the "Execution requirements" column is described in clause 4.5.2. 


Rel-x 
Terminal: 


For a given Release, the corresponding "Rel-x Terminal" column lists the tests required for a Terminal to 
be declared compliant to this Release. 


Support: 


The "Support" column is blank In the proforma, and is to be completed by the manufacturer in respect of 
each particular requirement to indicate the choices, which have been made In the Implementation. 



3.4.3 Status and Notations 

The "Rel-x Terminal" columns show the status of the entries as follows: 

The following notations, defined in ISO/IEC 9646-7 [7], are used for the status column: 



M 

O 

N/A 

X 

O.i 

Ci 



mandatory - the capability is required to be supported. 

optional - the capability may be supported or not. 

not applicable - in the given context, it is impossible to use the capability. 

prohibited (excluded) - there is a requirement not to use this capability in the given context. 

qualified optional - for mutually exclusive or selectable options from a set. "i" is an integer which 
identifies an unique group of related optional items and the logic of their selection which is 
defined immediately following the table. 

conditional - the requirement on the capability ("M", "O", "X" or "N/A") depends on the support 
of other optional or conditional items, "i" is an integer identifying an unique conditional status 
expression which is defined immediately following the table. For nested conditional expressions, 
the syntax "IF ... THEN (IF ... THEN ... ELSE...) ELSE ..." is to be used to avoid ambiguities. 
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References to items 

For each possible item answer (answer in the support column) there exists a unique reference, used, for example, in the 
conditional expressions. It is defined as the table identifier, followed by a solidus character "/", followed by the item 
number in the table. If there is more than one support column in a table, the columns are to be discriminated by letters 
(a, b, etc.), respectively. 



EXAMPLE: 



A. 1/4 is the reference to the answer of item 4 in table A. 1 . 



Test environment 



4.1 Table of optional features 

The supplier of the implementation shall state the support of possible options in table 4.1. See clause 3.4 for the format 
of table 4.1. 

Table 4.1 : Options 



Item 


Option 


Status 


Support 


Mnemonic 


1 


Class B 







CLASS B 


2 


Class C full power mode 







CLASS C FULL 


3 


Class C low power mode 







CLASS C LOW 


4 


Extended bit durations 







EXTENDED T 


5 


SREJ supported 







SREJ 


6 


Terminal supports DEACTIVATED followed 
by subsequent SWP interface activation in full 
power mode 







0_DEAC_SUBACT_FULL 


7 


Window size of 3 







WS 3 


8 


Window size of 4 (see note) 







WS 4 


9 


HCI as per TS 1 02 622 [4] 







102 622 


10 


CLT, ISO/I EC 14443-3 [5] Type A 







CLT A 


11 


CLT, ISO/IEC18092[8] 







CLT F 


12 


Void 








13 


Void 








14 


USB as per TS 102 600 [3] 







102 600 


15 


Void 








16 


Terminal can be switched from full power 
mode directly to low power mode without 
disconnecting the antenna or removing the 
power supply. 







0_FULL_T0_L0W 


17 


Terminal can be switched from low power 
mode with the power supply connected 
directly to full power mode without 
disconnecting the antenna. 







0_L0W_T0_FULL 


18 


Card Emulation, ISO/IEC 14443-4 [6] type A 







CE A 


19 


Card Emulation, ISO/IEC 14443-4 [6] type B 







CE B 


NOTE: If the terminal supports WS 4, then it also shall support WS 3. | 
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4.2 Applicability table 

Table 4.2 a) specifies the applicability of each test case to the device under test. See clause 3.4 for the format of table 4.2 a). 

Table 4.2 a): Applicability of tests 



Test case 


Description 


Release 


Execution 
requirements 


Rel-7 
Terminal 


Rel-8 
Terminal 


Rel-g 
Terminal 


Support 




System architecture tests 
















(Test cases for this clause are FFS) 
















Physical characteristics tests 














5.3.2.2.2 


activation of SWP additionally to other interface 


Rel-7 




C001 


C001 


C001 




5.3.2.2.3 


activation of SWP in low power mode 


Rel-7 




C002 


C002 


C002 




5.3.2.3.2 


SWP initial activation in full power mode - normal procedure 


Rel-7 




C001 


C001 


C001 




5.3.2.3.3 


SWP Initial activation - no resume 


Rel-7 




M 


M 


M 




5.3.2.3.4 


SWP initial activation in full power mode - corrupted ACT_SYNC frame (repeat the last 
frame) 


Rel-7 




C001 


C001 


C001 




5.3.2.3.5 


SWP initial activation in full power mode - no ACT SYNC frame (repeat the last frame) 


Rel-7 




C001 


C001 


C001 




5.3.2.3.6 


SWP initial activation failed in full power mode - corrupted ACT SYNC frame (multiple) 


Rel-7 




C001 


C001 


C001 




5.3.2.3.7 


SWP initial activation failed in full power mode - no ACT SYNC frame (multiple) 


Rel-7 




C001 


C001 


C001 




5.3.2.3.8 


SWP Initial activation in full power mode - corrupted ACT_READY frame (repeat last 
frame) 


Rel-7 




C001 


C001 


C001 




5.3.2.3.9 


SWP Initial activation in full power mode - no ACT READY frame (repeat last frame) 


Rel-7 




C001 


C001 


C001 




5.3.2.3.10 


SWP initial activation failed in full power mode - corrupted ACT_READY frame 
(multiple) 


Rel-7 




C001 


C001 


C001 




5.3.2.3.11 


SWP initial activation failed in full power mode - no ACT READY frame (multiple) 


Rel-7 




C001 


C001 


C001 




5.3.2.3.12 


SWP initial activation in low power mode 


Rel-7 




C002 


C002 


C002 




5.3.2.3.13 


SWP initial activation in low power mode - corrupted ACT_SYNC frame (repeat the 
last frame) 


Rel-7 




C002 


C002 


C002 




5.3.2.3.14 


SWP initial activation in low power mode - no ACT_SYNC frame (repeat the last 
frame) 


Rel-7 




C002 


C002 


C002 




5.3.2.3.15 


SWP initial activation failed in low power mode - corrupted ACT_SYNC frame 
(multiple) 


Rel-7 




C002 


C002 


C002 




5.3.2.3.16 


SWP initial activation failed in low power mode - no ACT SYNC frame (multiple) 


Rel-7 




C002 


C002 


C002 




5.3.2.3.17 


SWP subsequent activation in full power mode 


Rel-7 




C001 AND 
COOS 


C001 
AND 
C006 


C001 
AND 
COOS 




5.3.2.3.19 


SWP initial activation in full power mode - send ACT frames in wrong order, 
ACT READY frame after activation (repeat the last frame) 


Rel-7 




C001 


C001 


C001 






Electrical characteristics tests 














5.4.1.3.2 


current provided in low power mode, no spikes 


Rel-7 




C002 


C002 


C002 




5.4.1.3.3 


current provided in low power mode, with spikes 


Rel-7 




C002 


C002 


C002 




5.4.1.4.2 


communication with S2 variation in full power mode 


Rel-7 




C001 


C001 


C001 




5.4.1.4.3 


communication with S2 variation in low power mode 


Rel-7 




C002 


C002 


C002 
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Test case 


Description 


Release 


Execution 
requirements 


Rel-7 
Terminal 


Rel-8 
Terminal 


Rel-9 
Terminal 


Support 


5.4.1.5.2.2 


communication with S2 variation in full power mode 


Rel-7 




C001 


C001 


C001 




5.4.1.5.2.3 


communication with S2 variation in low power mode 


Rel-7 




C002 


C002 


C002 






Physical transmission layer tests 














5.5.1.2 


SI waveforms, default bit duration 


Rel-7 




M 


M 


M 




5.5.1.3 


S1 waveforms, extended bit durations 


Rel-7 




C013 


C013 


C013 




5.5.3.2 


SWP states and transitions, communication 


Rel-7 




M 


M 






5.5.4.2 


power provided in full power mode, SWP 


Rel-7 




C001 


C001 


C001 




5.5.4.3 


switching from full to low power mode 


Rel-7 




Clio 


Clio 


Clio 




5.5.4.4 


switching from low to full power mode 


Rel-7 




cm 


cm 


cm 






Data link layer tests 














5.6.2.2.2 


interpretation of incorrectly formed frames - SHDLC RSET frames 


Rel-7 




M 


M 


M 




5.6.2.2.3 


interpretation of incorrectly formed frames - SHDLC l-frames 


Rel-7 




M 


M 


M 




5.6.2.3.2 


behavior of CLF with bit stuffing in frame 


Rel-7 




M 


M 


M 




5.6.3.2.2 


ignore ACT LLC frame reception after the SHDLC link establishment 


Rel-7 




M 


M 


M 




5.6.3.2.3 


ignore ACT LLC frame reception in CLT session 


Rel-7 




C011 


coil 


con 




5.6.3.2.5 


closing condition of CLT session whereas SHDLC link has been established before 
CLT session 


Rel-7 




coil 


C011 


con 




5.6.4.2.2 


not matching SYNC_ID verification in low power mode 


Rel-7 




C002 
AND 
COOS 
AND 
C009 


C002 
AND 

coos 

AND 
C009 


C002 
AND 
COOS 
AND 
C009 






SHDLC LLC definition tests 














5.7.1.2 


data passed up to the next layer 


Rel-7 




C009 


C009 


C009 




5.7.1.3 


error management - corrupted l-frame 


Rel-7 




M 


M 


M 




5.7.1.4 


error management - corrupted RR frame 


Rel-7 


TR1 


M 


M 


M 




5.7.6.4.2 


initial state at link reset - reset by the UICC 


Rel-7 


TR1 


M 


M 


M 




5.7.7.3.2 


link establishment by the UICC 


Rel-7 




M 


M 


M 




5.7.7.3.3 


Link establishment and connection time out 


Rel-7 




M 


M 


M 




5.7.7.3.4 


requesting unsupported window size and/or SREJ support - link establishment by 
UICC 


Rel-7 




CI 07 


C107 


CI 07 




5.7.7.3.5 


forcing lower window size and SREJ not used - link establishment by the T 


Rel-7 




C10S 


CI 08 


C10S 




5.7.7.3.6 


discard buffered frames on link re-establishment 


Rel-7 




CI 02 


C102 


CI 02 




5.7.7.5.2 


l-frame transmission 


Rel-7 


TR2/TR1 
(see note) 


M 


M 


M 




5.7.7.5.3 


l-frame reception - single l-Frame reception 


Rel-7 


TR2/TR1 (see 
note) 


M 


M 


M 




5.7.7.5.4 


l-frame reception - multiple l-Frame reception 


Rel-7 


TR2/TR1 (see 
note) 


M 


M 


M 




5.7.7.6.2 


REJ transmission - multiple l-frames received 


Rel-7 




C101 


C101 


C101 




5.7.7.6.3 


REJ reception 


Rel-7 


TR2/TR1 
(see note) 


M 


M 


M 




5.7.7.7.2 


retransmission of multiple frames 


Rel-7 


TR2/TR1 
(see note) 


M 


M 


M 
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Test case 


Description 


Release 


Execution 
requirements 


Rel-7 
Terminal 


Rel-8 
Terminal 


Rel-9 
Terminal 


Support 


5.7.7.8.2 


RNR reception 


Rel-7 


TR2/TR1 
(see note) 


M 


M 


M 




5.7.7.8.3 


Empty l-frame transmission 


Rel-7 


TR1 


M 


M 


M 




5.7.7.9.2 


SREJ transmission 


Rel-7 




CI 02 


C102 


CI 02 




5.7.7.9.4 


SREJ reception 


Rel-7 


TR2/TR1 
(see note) 


CI 02 


CI 02 


CI 02 






CLT LLC definition tests 














5.8.5.2 


ISO/IEC 14443-3 [5] Type A, no administrative command 


Rel-7 


TR1 


COOS 


COOS 


COOS 




5.8.6.3.1.2 


opening a CLT session with CL PROTO INF(A) 


Rel-7 


TR1 


COOS 


COOS 


COOS 






Timing and performance tests 














5.9.1.2.2 


Transceiving non-chained data over RF in Card Emulation 


Rel-7 


TR2 


N/A 


N/A 


C112 




5.9.2.1.2 


CLE processing time - Type A aligned communication, with RF response 


Rel-7 


TR1 


COOS 


COOS 


COOS 




5.9.2.1.3 


CLE processing time, no RF response 


Rel-7 


TR1 


COOS 


COOS 


COOS 




5.9.2.2.2 


CLE processing time. Request Guard Time from IDLE state - Type A state transition 


Rel-7 


TR1 


COOS 


COOS 


COOS 




5.9.2.2.3 


CLE processing time. Request Guard Time from HALT state - Type A state transition 


Rel-7 


TR1 


COOS 


COOS 


COOS 




NOTE: The test case shall be executed with TR2 if available, otherwise TR1 shall be used. 
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Table 4.2 b): Conditional items referenced by table 4.2 a) 



Conditional item 


Condition 


C001 


IF(0 CLASS BORO CLASS C FULL) THEN M ELSE N/A 


C002 


IF CLASS C LOW THEN M ELSE N/A 


COOS 


Void 


C004 


Void 


COOS 


IFO 102 600 THEN M ELSE N/A 


C006 


IFO DEAC SUBACT FULL THEN M ELSE N/A 


C007 


Void 


COOS 


IF CLT A THEN M ELSE N/A 


C009 


IFO 102 622 THEN M ELSE N/A 


C010 


Void 


con 


IF CLT A OR CLT F THEN M ELSE N/A 


C012 


Void 


C013 


IFO EXTENDED T THEN M ELSE N/A 


C101 


IFO WS 3 THEN M ELSE N/A 


C102 


IF SREJ THEN M ELSE N/A 


C103 


Void 


CI 04 


Void 


CI 05 


Void 


C106 


IF SREJ AND WS 3 THEN M ELSE N/A 


CI 07 


IF NOT (0 SREJ AND WS 4) THEN M ELSE N/A 


C108 


IF WS 3 OR SREJ THEN M ELSE N/A 


CI 09 


Void 


C110 


IF(0 CLASS C LOW AND (0 CLASS BORO CLASS C FULL)) AND FULL TO LOW THEN M ELSE N/A 


cm 


IF(0 CLASS C LOW AND (0 CLASS BORO CLASS C FULL)) AND LOW TO FULL THEN M ELSE N/A 


C112 


IF(0 CE A OR CE B)THEN M ELSE N/A 



Table 4.2 c): Execution requirements referenced by table 4.2 a) 



Execution 
requirement 


Description 


TR1 


HCI is used if available 


TR2 


If the terminal supports HCI-based Card Emulation using the UICC for either technology A or B, 


a PCD (ISO/IEC 14443-4 [6] compliant) shall be used. 



The details for setting up the execution requirements are specified in clause 4.4.4. 
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4.3 Information provided by the device supplier 

Some test cases require that the test equipment triggers the terminal to perform further communication over SHDLC or 

CLT after performing an SWP activation. 

Some other test cases require the modification of the power supply during the test execution. 

The device supplier shall provide enough information to allow this to be carried out. 

SHDLC timings measurements require the following information. 



Item 


Description 


Presence/Value 


Status 


Mnemonic 


1 


Frame size used by the CLF in Card Emulation for technology 
A (FSC parameter defined in ISO/IEC 14443-4 [6]) 




C 


V_FRAIV1E_SIZE_CEA 


2 


Frame size used by the CLF in Card Emulation for technology 

B 

(Max Frame Size in Protocol Info, as defined in 

ISO/IEC 14443-3 [5]) 




C 


V_FRAME_SIZE_CEB 


NOTE: Conditional values shall be provided if the corresponding option is supported in the table 4.1 . 



4.4 Test equipment 



The test equipment shall provide a UICC simulator which is connected to the DUT during test procedure execution, 
unless otherwise specified. 

With respect to the Terminal and CLF, the UICC simulator shall act as a valid UICC according to TS 102 613 [1], 
TS 102 221 [2], and TS 102 600 [3] (if this interface is present at the UICC), unless otherwise specified. In particular, 
during test procedure execution, the UICC simulator shall respect the electrical and signalling conditions for all UICC 
contacts within the limits given by TS 102 613 [1], TS 102 221 [2] and TS 102 600 [3]). The accuracy of the UICC 
simulator's settings shall be taken into account when ensuring this. 

For some test cases, usage of a PCD is required. The detailed requirements are specified in the individual test cases in 
addition to the requirements in the current clause. In particular the test equipment shall provide a trigger mechanism 
based on a PCD, for performing test cases with terminal activation in low power mode. The registry definitions in 
clause 4.4.4.2 for RF type A and RF type B shall be used when initialising the terminal in full power mode. 

The test equipment shall ensure that a matching SYNC_ID is used during test case execution, unless otherwise 
specified. 

Some test cases might require the presence of an upper layer, such as HCI (as specified in TS 102 622 [4]). The test 
equipment shall provide this layer if required. Any HCI session initialization shall comply to the procedure defined in 
TS 102 622 [4]. If message fragmentation is used, all HCP packets, with the possible exception of the last packet, shall 
contain the maximum amount of data possible for HCP packets. Additionally, some test cases might require the 
presence of an NAA (e.g. (U)SIM), which shall be provided by the test equipment. 

NOTE: The implementation of the terminal may imply certain activities or settings on the HCI layer. This should 
be taken into account when testing the SWP interface (e.g. activity after initialization, already open pipes, 
etc.). 

4.4.1 Measurement / setting uncertainties 

The following accuracy applies for measurement and setting of electrical parameter for the test equipment. 
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Table 4.3 a): Measurement accuracy 



Parameter 


Tolerance 


Remark 


Vcc 


±50 mV 




VoH^ 

Vol 


±15 mV 




T 


±25 ns 




tr, tf 


±5 ns, if tr/f < 1 00 ns 

±1 ns, if tr/f > 1 00 ns 

(see note) 




"•"si HIGH V 


±20 ^s 




P3 


±100 ns 




P4 


±1 MS 




T2, T3 


±100 MS 




"'"CLF,shdlc, receive, 

^CLF.shdlc, transmit, 
TCLF,delay 


±10 MS 




NOTE: In the present document, the validation of rise/fall times against the minimum 
allowed value (5 ns) shall not be carried out by the test equipment. 



Table 4.3 b): Setting uncertainty 



Parameter 


Tolerance 


Remark 


'cc 


±0,1 mA 




Ih 


±25 mA 




II 


±5 mA 




Spike duration 
(see clause 5.4.1.3.3) 


±25 ns 




UICC processing time for CLT 


±5 MS 





For settings which specify the maximum or minimum allowed values according to TS 102 613 [1], the requirements of 
table 4.3 b) are modified as follows: 

• For setting a value X which is a minimum allowed value according to TS 102 613 [1], the test equipment shall 
set the nearest available value which is guaranteed to not be smaller than X, within the setting uncertainty of 
the test equipment. 

• For setting a value X which is a maximum allowed value according to TS 102 613 [1], the test equipment shall 
set the nearest available value which is guaranteed to not be larger than X, within the setting uncertainty of the 
test equipment. 

For example, when setting a value for Ijj (where the allowed values are from 600 mA to 1 000 mA) and when the 
accuracy of the test equipment is 20 m A: 

• If a value of 600 m A is required, the test equipment shall set a value of 620 m A. 

• If a value of 1 000 m A is required, the test equipment shall set a value of 980 m A. 

4.4.2 Default conditions for DUT operation 

Unless otherwise specified, the test equipment shall apply the default conditions described in the following clauses 
during test procedure execution. 



4.4.2.1 

Void. 



Temperature 
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4.4.2.2 



TS 102 221 interface contacts (CLK, RST, I/O) and contact Vcc 



Tables 4.4 and 4.5 give the electrical conditions that shall be applied by the UICC simulator to all contacts during a test 
if not stated otherwise. 

Table 4.4: Nominal test conditions on 3 V UlCC-Terminal interface 



Contacts 


Low level 


High level 


Max. capacitive load 


C1 (VCC) 


... 


1 = 7.5 mA 




C2 (RST) 


1 = -200 mA 


1 = +20 mA 


30 pF 


C3 (CLK) 


1 = -20 [XA 


1 = +20 ^A 


30 pF 


C5 (GND) 


... 


... 




C7 (I/O) 
Terminal input 
Terminal output 


1 = +1 mA 
1 = -1 mA 


1 = +20 liA 
1 = +20 liA 


30 pF 


Table 4.5: Nominal test conditions on 1,8 V UlCC-Terminal interface 


Contacts 


Low level 


High level 


Max. capacitive load 


C1 (VCC) 


... 


l = 5mA 




C2 (RST) 


1 = -200 mA 


1 = +20 mA 


30 pF 


C3 (CLK) 


1 = -20 [xA 


1 = +20 ^A 


30 pF 


C5 (GND) 


... 


... 




C7 (I/O) 
Terminal input 
Terminal output 


I = +1 mA 
1 = -1 mA 


1 = +20 mA 
1 = +20 liA 


30 pF 



4.4.2.3 

Void. 



TS 102 600 interface contacts (IC_DP, IC_DM) 



4.4.2.4 TS 1 02 61 3 interface contact (SWIO) 

When activated, the UICC simulator shall maintain the characteristics on this contact in following range: 

• S2 signal levels applied: 

State H between 650 |iA and 950 |iA. 

State L between |iA and 15 |iA. 

Following each resume by the UICC simulator, the test equipment shall use the following S2 bit pattern: 
"R I 1 I W I P' bit of SOF" unless otherwise specified (see clause 5.5.3 for the meaning of this pattern). 

4.4.2.5 Status of UICC Interfaces 

The UICC simulator shall not attach on the TS 102 600 [3] interface. 



4.4.2.6 



Characteristics of LLC's 



4.4.2.6.1 



ACT LLC 



ACT_SYNC frames sent by the UICC simulator during initial interface activation shall contain an 
ACTJNFORMATION field, as specified in TS 102 613 [1]. 

ACT_READY frames sent by the UICC simulator during initial interface activation shall not contain an 
ACT_INFORMATION field. 

ACT frames sent by the UICC simulator during subsequent interface activation shall not contain an 
ACT_INFORMATION field, as specified in TS 102 613 [1]. 
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4.4.2.6.2 SHDLC LLC 

For SHDLC link establishment, the UICC simulator shall send RSET(). 

I-frames sent by the UICC simulator shall contain at least 1 byte and shall contain valid messages according to the 
context of the upper layer, i.e. the contents of the I-frames shall not provoke error conditions in the upper layer of the 
DUT. 

If the upper layer is HCI according to TS 102 622 [4], then simultaneous fragmentation of HCI messages over more 
than one pipe shall not be used. 

4.4.2.6.3 CLT LLC 

The following convention applies: For ISO/IEC 14443-3 [5] communication, the number of RF bytes in the test cases 
include the CRC, but not the framing and parity bits (i.e. when referring "4 RF bytes", the resulting RF frame consists 
of SOF, 4 bytes + 1 bit parity for each, EOF). 

The test tool shall respond to CLT_A commands within 5 ms. 

4.4.3 Minimum/maximum conditions for DUT operation 

Void. 

4.4.4 Execution requirements 

Table 4.2, Applicability of tests, specifies trigger requirement (TRn) for several test cases, to trigger the DUT to 
perform a particular operation in order to test a certain feature, since the core specification (TS 102 613 [1]) does not 
provide a standardized mechanism to trigger that operation. 

4.4.4.1 Definition of TR1 

The choice of the implementation for this trigger requirement is left up to the test tool provider. However, as a 
guideline, it is expected that the implementation only relies on the 2 interfaces available (SWP/HCI and RF) such that 
the test tool can have a full control of the mechanism and does not require any user action. 

4.4.4.2 Definition of TR2 

If the terminal supports HCI-based Card Emulation for either technology A or B, a Proximity Coupling Device (PCD, 
ISO/IEC 14443-4 [6] compliant) shall be used to perform the trigger requirement TR2. 

The test procedure shall be performed from ISO/IEC 14443-3 [5] ACTIVE state with the following parameters: 

• For terminal supporting ISO/IEC 14443-3 [5] type A, the following registry entries shall apply for the RF gate 
typeA, TS 102 622 [4]: 

UID_REG = '01 02 03 04' (single UID). 

SAK = '20' (ISO/IEC 14443-4 [6] compliant). 

ATQA = '00000000 OOOOOOOl'b (single UID, anti-collision bit). 

APPLICATION_DATA = null (no historical bytes). 

FWI, SFGI = '81' (SFGT = 604 |is & FWT = 77,33 ms). 

CID_SUPPORT = '00' (default value, CID support not required). 

DATARATE_MAX = '000000' (106 kb/s only). 

MODE = '02'. 
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• For terminal supporting ISO/IEC 14443-3 [5] type B the following registry entries shall apply for the RF gate 
typeB,TS 102 622 [4]: 

PUPI = '01 02 03 04'. 

AFI = '40'. 

ATQB is coded for the following values: PROTOJNFO = '70' & NUMBER_APLI = -15. 

HIGHER_LAYER_RESPONSE = null (no bytes). 

MODE = '02'. 

For both technologies, C-APDU size shall be adapted to each test case, to generate the right number of I-Frames on 
SWP. 

4.5 Test execution 

4.5.1 Parameter variations 

Unless otherwise specified, all tests shall be carried out once for each voltage class and power mode available in the 
terminal in addition to the parameter variations specified individually for each test case. 

4.5.2 Execution requirements 

Table 4.2, Applicability of tests, specifies "execution requirements" for several test cases. 
An example of test requirements is: 

• The test case requires the DUT to perform a particular operation in order to test that feature, but the core 
specification (TS 102 613 [1]) does not provide a standardized mechanism to trigger that operation to be 
executed by the DUT. 

The test requirements have been split into various categories, as indicated by table 4.2 c): 

• Static requirements (SRx): information about, for example, particular parameters which can be used in the test 
procedure execution. 

• Trigger requirements (TRx): mechanisms for triggering the DUT to perform certain operations. 

• Initial condition requirements (ICRx): information about how to establish initial condition states. 

The DUT supplier should make every effort to provide appropriate information or mechanisms to allow these execution 
requirements to be satisfied for the DUT. 

It is recognised that this might not always be possible. For example, if the configuration of the DUT does not allow for 
the required state to be present; or if it is not possible to provide a particular trigger mechanism for the DUT. In these 
cases, it is acceptable that the test case is not carried out. However, it should be recognised that the consequence is that 
the particular feature will not be tested. 

4.6 Pass criterion 

A test shall only be considered as successful if the test procedure was carried out successfully under all parameter 
variations with the DUT respecting all conformance requirements referenced in the test procedure. 

NOTE: Within the test procedures, the RQs are referenced in the step where they are observable. In some cases, 
this is different from the step where they occur with respect to the DUT. 
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5 Test cases 

5.1 Principle of the Single Wire Protocol 

Reference: TS 102 613 [1], clause 4. 
There are no conformance requirements for the terminal for the referenced clause. 

5.2 System architecture 

5.2.1 General overview 

Reference: TS 102 613 [1], clause 5.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.2.2 TS 102 221 support 
5.2.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 5.2. 



RQ1 I A terminal supporting SWP shall remain compliant with TS 1 02 221 [2], 



NOTE: The validation of RQ1 is out of scope of the present document. Compliancy to RQ1 can be verified by 
running testcases described in other related test specifications. 



5.2.3 Configurations 

5.2.3.1 Conformance requirements 

Reference: TS 102 613 [1], clause 5.3. 



RQ1 



The terminal shall indicate the support of SWP interface in the terminal capability as defined in TS 102 221 [2]. 



RQ2 



If the SWP interface is activated while a session on TS 102 600 [3] interface is in progress, actions on the SWP 
interface shall not disturb the terminal-UiCC exchange on the TS 102 600 [3] interface. 



RQ3 



If the SWP interface is activated while a session on the TS 102 600 [3] interface is in progress actions on the 
TS 102 600 [3] interface shall not disturb the terminal-UICC exchange on the SWP interface. 



RQ4 



If the SWP interface is activated while a session on the TS 102 221 [2] interface is in progress actions on the 
SWP interface shall notdisturb the terminal-UICC exchange on the TS 102 221 [2] interface. 



RQ5 



If the SWP interface is activated while a session on the TS 102 221 [2] interface is in progress actions on the 
TS 102 221 [2] interface shall not disturb the terminal-UICC exchange on the SWP interface. 



NOTE: Development of test cases for RQIto RQ5 is FFS. 
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5.2.4 Interaction with otiner interfaces 



5.2.4.1 Conformance requirements 

Reference: TS 102 613 [1], clause 5.4. 



RQ1 



Signaling on a contact assigned to one interface shall not affect the state of other contacts assigned to 
another interface. This also applies to the activation sequence of the UICC. 



Operation of the SWP interface after activation shall be independent from operation of other interfaces 
^e.g. the TS 102 221 [2] orTS 102 600 [3] interface) that may be implemented on the UICC. 



RQ2 



RQ3 



A logical reset signaling on the data link layer (SHDLC RSET) over the SWP interface shall not affect any 
of the other interfaces. 



RQ4 lActivation and deactivation of SWP interface shall not affect any of the other interfaces. 

NOTE: Test cases for these requirements will not be provided, as independency of the interfaces cannot be 
ensured. 



5.3 Pinysical cliaracteristics 

5.3.1 Temperature range for card operations 
5.3.1.1 Conformance requirements 

Reference: TS 102 613 [1], clause 6.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.3.2 Contacts 



5.3.2.1 



Provision of contacts 



5.3.2.1.1 Conformance requirements 

Reference: TS 102 613 [1], clause 6.2.1. 
All conformance requirements for the referenced clause are included in clause 5.3.2.2 of the present document. 



5.3.2.2 



Contact activation and deactivation 



5.3.2.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 6.2.1. 



RQ101 



The terminal shall reuse the \/qq (contact CI) and Gnd (contact C5) provided in the UICC to provide 
power supply. 



RO102 



The terminal shall use SWIO (contact C6) for data exchange (i.e. SWP) between UICC and the CLF. 
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Reference: TS 102 613 [1], clause 6.2.3.1, RQ6 and RQ7 refers to clause 8.1 and RQ 7 refers also to clause 8.3. 



RQ1 



The terminal shall connect, activate and deactivate contacts C2, C3 and C7 of the UICC in accordance with the 
operating procedures specified in TS 102 221 [2]. 



RQ2 



The terminal shall connect, activate and deactivate contacts C4 and C8 in accordance with the operating 
procedures specified in TS 102 600 [3]. 



RQ3 



The terminal shall activate the contact C1 (Vqc) according to TS 102 221 [2]. 



RQ4 



As long as Mqq (Contact CI) is not activated, the terminal shall keep SWIO (contact C6) deactivated (SI state L). 



RQ5 



The terminal shall activate the V^q (Contact CI ) in order to activate SWP interface or another Interface on the 
UICC. 



RQ6 



The terminal shall activate the SWIO (Contact C6) by setting the SWIO signal from state L to state H not sooner 
than Tg^ ^|q|_| y after Vqq (Contact C1) activation, with a rise time of tr = 5 ns to 250 ns. 



RQ7 



The terminal shall deactivate SWIO (contact C6) by setting SWP to the DEACTIVATED state with a fall time of 
tf = 5 ns to 250 ns, that is by maintaining SWIO in state L for longer than deactivation time P4. 



RQ8 



The terminal shall deactivate SWIO (contact C6) before or at the same time as deactivating V^q (Contact CI) 



5.3.2.2.2 



5.3.2.2.2.1 



Test case 1 : activation of SWP additionally to other interfaces 



Test execution 



The test procedure shall only be executed in voltage class B, if available, and voltage class C, full power mode, if 
available. 

The test procedure shall be performed with the following parameters: 

• The UICC indicating the support of the TS 102 600 [3] interface in the ATR, if sent. 

• The UICC not indicating the support of the TS 102 600 [3] interface in the ATR, if sent. 

5.3.2.2.2.2 Initial conditions 

• None of the UICC contacts is activated. 



5.3.2.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate the UICC 




2 


T^UICC 


Depending on the terminal capability and status one of the following shall 
occur: 

• Activate Vcc (contact C1 ), contacts C2, C3 and C7 for TS 1 02 221 [2] 
interface activation and SWIO (contact C6) 

• Activate Vcc (contact CI), contacts C4 and C8 for USB interface 
activation and SWIO (contact C6) 

• Activate Vcc (contact CI ), contacts C2, C3 and C7 for TS 1 02 221 [2] 
interface activation followed by activation of contact C4 and C8 and 
SWIO (contact C6) 

• Activate Vcc (contact CI ) and SWIO (contact C6) 


RO101 
R01 
R02 
R03, 
R04, 
R05 
R06 


3 


UICC 4-^ T 


Perform initial SWP interface activation 


RQ102 


4 


User-> T 


Trigger the terminal to deactivate the UICC 




5 


T-»UICC 


Deactivate the UICC 


R07, 
R08 



5.3.2.2.3 



Test case 2: activation of SWP in low power mode 



5.3.2.2.3.1 Test execution 

The test procedure shall only be performed for voltage class C, low power mode. 
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5.3.2.2.3.2 Initial conditions 

• None of the UICC contacts is activated. 



5.3.2.2.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User -^T 


Trigger the terminal to activate contact V^q and SWIO 




2 


T^ UICC 


Activate Vcc (contact C1) 


R03, 
R04, 
R05 


3 


T^ UICC 


Activate SWIO (contact C6) 


RQ6 


4 


UICC ^^T 


Perform initial SWP interface activation (see note) 




5 


User ^T 


Trigger the terminal to deactivate contacts V^q and SWIO 




6 


T^ UICC 


Deactivate SWIO (contact C6) 


R07 


7 


T^UICC 


Deactivate Vcc (contact C1) 


R08 


NOTE: The initial SWP interface activation is complete when UICC has sent the ACT_SYNC frame. There 
could be more frames exchanged, but this is not a failure of the terminal. 



5.3.2.3 



Interface activation 



5.3.2.3.1 Conformance requirements 

Reference: TS 102 613 [1], clause 6.2.3 and subclauses. 

The following conformance requirements apply to initial interface activation as specified in TS 102 613 [1], 
clause 6.2.3.1; the requirements are also presented in a state diagram (see clause A. 2). 



RQ1 



In case the CLF does not detect a SWP resume by the UICC, the CLF shall deactivate SWIO (contact 
C6). 



R02 



In case the CLF detects a SWP resume by the UICC, the CLF shall put SWP into ACTIVATED state. 
If the CLF has received a correct ACT_SYNC frame and the terminal provides low power mode, the CLF 
shall consider the initial interface activation as being successful and shall not send further ACT frames. 



R03 



R04 



If the CLF has received a correct ACT_SYNC frame and the terminal provides full power mode, the CLF 
shall send an ACT_POWER_IVIODE frame with FR bit set to Oindicating full power mode. 



RQ5 



When the CLF has received a corrupted frame or no frame the CLF shall request the UICC to repeat the 
last ACT_SYNC frame by sending an ACT_POWER_MODE frame with FR bit set to 1 indicating the 
terminal power mode. 



R06 



If the CLF has received a correct ACT_SYNC frame in response to an ACT_POWER_MODE frame with 
FR bit set to 1 , it shall consider that the initial interface activation as being successful and shall not send 
further ACT frames. 



RQ7 



If the CLF has received a correct ACT_READY frame in the case that the CLF has previously correctly 
received the first ACT_SYNC frame from the UICC, it shall consider the initial interface activation as being 
successful and shall not send further ACT frames. 



R08 



When the CLF has received a corrupted ACT frame in response to an ACT_POWER_MODE frame it shall 
request the UICC to repeat the last ACT frame by sending an ACT_POWER_MODE frame with FR bit set 
to 1 indicating the terminal power mode. 



RQ9 



When the CLF has not received an ACT frame in response to the ACT_POWER_IVIODE frame it shall 
request the UICC to repeat the last ACT frame by sending the ACT_POWER_MODE with FR bit set to 1 
indicating the terminal power mode. 



RQ10 



The CLF shall not send more than three ACT POWER MODE frames with the FR bit set to 1 . 



RQ11 



If the interface activation was not successful the CLF shall assume that the UICC doesn't support SWP 
and shall deactivate SWIO (contact C6). 



RQ12 



The CLF shall treat a received ACT frame like a corrupted frame when it does not occur in the order 
defined in the sequence above. 
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The following conformance requirements apply to subsequent interface activation as specified in TS 102 613 [1], 
clause 6.2.3.2. 



RQ13 



The initial interface activation sequence as specified in RQ1 to RQ12 shall also be applied after the 
transition of S1 to state H from the state DEACTIVATED. 



RQ14 



If the CLF has received a correct ACT_SYNC frame, the CLF shall immediately consider the subsequent 
interface activation as being successful and shall not send further ACT frames. 



NOTE: These RQs are not tested for low power mode, as it is not possible to trigger a subsequent activation 
in low power mode. 



The following conformance requirements apply to initial and/or subsequent interface activation as specified in 
TS 102 613 [1], clause 6.2.3.3. 



RQ15 



For initial interface activation, the CLF shall be able to detect an SWP resume by the UICC between |as 
and 700 ps (Tga act_res_v)- 



RQ16 



The CLF shall be able to detect UICC responses to ACT_POWER_IVIODE frames where the SWP 
resume or wakeup sequence starts between [xs and 2000 ps (Tgg ^ct frp)- 



RQ17 



For subsequent interface activation the CLF shall be able to detect an SWP resume by the UICC 
between \as and 500 ps (Tgg ^qj p^g d)- 



NOTE: RQ1 7 is not tested for low power mode, as it is not possible to trigger a subsequent activation in low 
power mode. 



The following conformance requirements apply to initial and/or subsequent interface activation as specified in 
TS 102 613 [1], clause 6.2.3.4. 



RQ18 



If the terminal operates the UICC in "low power mode" the terminal shall not activate the TS 102 221 [2] 
interface. 



RQ19 



If the terminal has activated the UICC according to TS 1 02 221 [2], the terminal shall consider the 
activation of the SWP interface as a selected application on the UICC. 



NOTE: Testing RQ1 9 is out of scope of the present document. 



The following conformance requirements apply to subsequent interface activation as specified in TS 102 613 [1], 
clause 8.1. 



RO20 



For a transition from DEACTIVATED state or for SWIO contact activation (proceeding the SWP 
interface activation procedure), the terminal shall apply a rise time tr of the signal S1 in the range of 5 
ns to 250 ns. 



NOTE: This RQ is not tested for low power mode, as it is not possible to trigger a subsequent activation in low 
power mode. 



The following conformance requirements are referenced to TS 102 613 [1], clause 9.3.1. 



R021 



After the SWIO activation or after the transition of SI to state H from DEACTIVATED state, the ACT LLC 
shall be used by the CLF. 



RQ22 



On receiving a corrupted SWP frame, the CLF shall use the error recovery procedure defined for LLC of 
the last correctly received SWP frame. 



RQ23 



Immediately after SWIO Activation or after the transition of S1 to state H from DEACTIVATED state, the 
error handling of the ACT LLC shall apply. 



Reference: TS 102 613 [1], clause 8.3. 



R024 



For a transition from SWP DEACTIVATED state to any other SWP state, the terminal shall initiate the 
subsequent interface activation sequence as per TS 102 613 [1]. 



NOTE: This RQ is not tested for low power mode, as it is not possible to trigger a subsequent activation in low 
power mode. 
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Reference: TS 102 613 [1], clause 9.4. 



RQ25 



The ACT LPDU shall be structured according to TS 102 613 [1]. 



RQ26 



The CLF shall set the INF bit to in all ACT frames sent to the UICC. 



RQ27 



When the CLF indicates low power mode by sending a ACT_POWER_l\/IODE frame then the 
ACT_DATA_FIELD byte shall be set to '00'. 



RQ28 



When the CLF indicates full power mode by sending a ACT_P0WER_IV10DE frame then the 
ACT_DATA_FIELD byte shall be set to '01'. 



RQ29 



RFU values for ACT_CTRL and ACT_DATA shall not be set by the CLF when transmitting frames. 



Reference: TS 102 613 [1], clause 6.2.5. 



RQ30 



When the terminal detects that the UICC does not support SWP, it shall keep SWIO in the deactivated 
state (state L). 



5.3.2.3.2 



5.3.2.3.2.1 



Test case 1 : SWP initial activation in full power mode - normal procedure 
Test execution 



The test procedure shall only be executed in voltage class B, if available, and voltage class C, full power mode, if 
available. 

The test procedure shall be performed with variation in the parameters T§2 act RES V '^^'^ ^S2 ACT FRP' ™ following 
values and combinations: 

* ''^Sl ACT RES V between 10 |is and 50 |is; T§2 act prp between 1 950 |is and 2 000 |is. 

* ''"si ACT RES V between 650 |is and 700 |is; Tg2 act prp between |is and 50 |is. 

5.3.2.3.2.2 Initial conditions 

* None of the UICC is activated. 



5.3.2.3.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate Vq^ and SWIO and to perform further 
communication over SHDLC or CLT (for example, by initiating a contactless 
card emulation session as specified in TS 1 02 622 [4]) 




2 


T^UICC 


Activate Vcc (contact CI) 




3 


T^ UICC 


Activate SWIO (contact C6) 




4 


UICC ^ T 


Resume SWP 




5 


T^ UICC 


Send transition sequence 


R02, 
RQ15 


6 


UICC-»T 


Send ACT SYNC frame 




7 


T^ UICC 


Send an ACT_POWER_MODE frame indicating full power mode with FR = 


R04, 
RQ16, 
RQ21, 
RQ25, 
RQ26, 
RQ28, 
RQ29 


8 


UICC -» T 


Respond with an ACT READY frame 




9 


T^ UICC 


Send RSET frame or send a CLT frame 


R07 
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5.3.2.3.3 



Test case 2: SWP Initial activation - no resume 



5.3.2.3.3.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• There are no test case-specific parameters for this test case. 

5.3.2.3.3.2 Initial conditions 

• None of the UICC simulator contacts is activated. 

• The ATR of the UICC simulator shall indicate that the TS 102 613 interface is not supported. 

5.3.2.3.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


User^ T 


Trigger the terminal to activate V^q, SWIO 




2 


T^ UICC 


Activate Vcc (contact C1) 




3 


T^ UICC 


Activate SWIO (contact C6) 

In the case of full power mode, if the terminal activates the TS 102 221 [2] 
interface before activating SWIO, the test procedure shall be stopped, This is 
not a failure of the terminal 




4 


UICC-»T 


No SWP resume 




5 


T^UICC 


Deactivate SWIO (contact C6) 


R01, 
RQ30 



5.3.2.3.4 Test case 3: SWP initial activation in full power mode - corrupted ACTSYNC 

frame (repeat the last frame) 



5.3.2.3.4.1 



Test execution 



The test procedure shall only be executed in voltage class B, if available, and voltage class C, full power mode, if 
available. 

5.3.2.3.4.2 Initial conditions 

• None of the UICC contacts is activated. 



5.3.2.3.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User -^ T 


Trigger the terminal to activate V^^, SWIO and to perform further 
communication over SHDLC or CLT (for example, by initiating a contactless 
card emulation session as specified in TS 1 02 622 [4]) 




2 


T^UICC 


Activate Vcc (contact CI) 




3 


T^UICC 


Activate SWIO (contact C6) 




4 


UICC^T 


Resume SWP 




5 


T-^ UICC 


Send transition sequence 


R02, 
RQ15 


6 


UICC ^ T 


Send corrupted ACT SYNC frame 




7 


T^ UICC 


Send an ACT_POWER_MODE frame indicating full power mode with FR=1 


R05, 
RQ16, 
RQ23 


8 


UICC^T 


Send ACT SYNC frame 




9 


T-»UICC 


Send RSET frame or send a CLT frame 


R06 
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5.3.2.3.5 Test case 4: SWP initial activation in full power mode - no ACTSYNC frame 

(repeat the last frame) 



5.3.2.3.5.1 



Test execution 



The test procedure shall only be executed in voltage class B, if available, and voltage class C, full power mode, if 
available. 

5.3.2.3.5.2 Initial conditions 

• None of the UICC contacts is activated. 



5.3.2.3.5.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate V^q, SWIO and to perform further 
communication over SHDLC or CLT (for example, by initiating a contactless 
card emulation session as specified in TS 1 02 622 [4]) 




2 


T^ UICC 


Activate Vcc (contact C1) 




3 


T^ UICC 


Activate SWIO (contact C6) 




4 


UICC^T 


Resume SWP 




5 


T^UICC 


Send transition sequence 


RQ2, 
RQ15 


6 


UICC 


No frame (set S2 to state L within 4 idle bits) 




7 


T^UICC 


Send an ACT_POWER_MODE frame indicating full power mode with FR=1 


RQ5, 
RQ16 


8 


UICC^T 


Send ACT SYNC frame 




9 


T^UICC 


Send RSET frame or send a CLT frame 


RQ6 



5.3.2.3.6 Test case 5: SWP initial activation failed in full power mode - corrupted 

ACT_SYNC frame (multiple) 



5.3.2.3.6.1 



Test execution 



The test procedure shall only be executed in voltage class B, if available, and voltage class C, full power mode, if 
available. 

5.3.2.3.6.2 Initial conditions 

• None of the UICC contacts is activated. 



£75/ 



Release 9 



32 



ETSI TS 102 694-1 V9.2.0 (2013-04) 



5.3.2.3.6.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User -» T 


Trigger the terminal to activate V(,(,, SWIO 




2 


T^ UICC 


Activate Vcc (contact CI) 




3 


T->UICC 


Activate SWIO (contact C6) 




4 


UICC^T 


Resume SWP 




5 


T^UICC 


Send transition sequence 


R02 


6 


UICC-^T 


Send corrupted ACT SYNC frame 




7 


T-^UICC 


Send an ACT_POWER_IVIODE frame indicating full power mode witti FR=1 


R05, 
RQ16 


8 


UICC^T 


Send corrupted ACT SYNC frame 




9 


T-^UICC 


Send an ACT_POWER_IVIODE frame indicating full power mode with FR=1 


R08, 
RQ16 


10 


UICC^T 


Send corrupted ACT SYNC frame 




11 


T^ UICC 


Send an ACT_POWER_MODE frame indicating full power mode with FR=1 


R08, 
RQ16 


12 


UICC^T 


Send corrupted ACT SYNC frame 




13 


T^ UICC 


Deactivate SWIO (contact C6) 


RQ10, 
RQ11 



5.3.2.3.7 Test case 6: SWP initial activation failed in full power mode - no ACT_SYNC 

frame (multiple) 



5.3.2.3.7.1 



Test execution 



The test procedure shall only be executed in voltage class B, if available, and voltage class C, full power mode, if 
available. 

5.3.2.3.7.2 Initial conditions 

• None of the UICC contacts is activated. 



5.3.2.3.7.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User -» T 


Trigger the terminal to activate V^q, SWIO 




2 


T^ UICC 


Activate Vcc (contact CI) 




3 


T^UICC 


Activate SWIO (contact C6) 




4 


UICC^T 


Resume SWP 




5 


T^UICC 


Send transition sequence 


R02, 
RQ15 


6 


UICC 


No frame (set S2 to state L within 4 idle bits) 




7 


T^UICC 


Send an ACT_POWER_IVIODE frame indicating full power mode with FR=1 


R05, 
RQ16 


8 


UICC 


No frame 




9 


T^ UICC 


Send an ACT_POWER_IVIODE frame Indicating full power mode with FR=1 


R09, 
RQ16 


10 


UICC 


No frame 




11 


T^ UICC 


Send an ACT_POWER_IVIODE frame indicating full power mode with FR=1 


R09, 
RQ16 


12 


UICC 


No frame 




13 


T^UICC 


Deactivate SWIO (contact C6) 


RQ10 
RQ11 
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5.3.2.3.8 Test case 7: SWP Initial activation in full power mode - corrupted ACT_READY 

frame (repeat last frame) 



5.3.2.3.8.1 



Test execution 



The test procedure shall only be executed in voltage class B, if available, and voltage class C, full power mode, if 
available. 

5.3.2.3.8.2 Initial conditions 

• None of the UICC contacts is activated. 



5.3.2.3.8.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate V^q, SWIO and to perform further 
communication over SHDLC or CLT (for example, by initiating a contactless 
card emulation session as specified in TS 1 02 622 [4]) 




2 


T^ UICC 


Activate Vcc (contact CI) 




3 


T^ UICC 


Activate SWIO (contact C6) 




4 


UICC^T 


Resume SWP 




5 


T^UICC 


Send transition sequence 


RQ2, 
RQ15 


6 


UICC-^T 


Send ACT SYNC frame 




7 


T^UICC 


Send an ACT_POWER_MODE frame indicating full power mode with FR = 


RQ4, 
RQ16 


8 


UICC^T 


Respond with corrupted ACT READY frame 




9 


T^ UICC 


Send an ACT_POWER_MODE frame indicating full power mode with FR=1 


RQ8, 
RQ16, 
RQ22 


10 


UICC^T 


Send a correct ACT READY frame 




11 


T-» UICC 


Send RSET frame or send a CLT frame 


RQ7 



5.3.2.3.9 Test case 8: SWP Initial activation in full power mode - no ACT_READY frame 

(repeat last frame) 



5.3.2.3.9.1 



Test execution 



The test procedure shall only be executed in voltage class B, if available, and voltage class C, full power mode, if 
available. 

5.3.2.3.9.2 Initial conditions 

• None of the UICC contacts is activated. 
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5.3.2.3.9.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate V(,(,, SWIO and to perform further 

communication over SHDLC or CLT (for example, by initiating a contactless 
card emulation session as specified in TS 1 02 622 [4]) 




2 


T^ UICC 


Activate Vcc (contact CI) 




3 


T^UICC 


Activate SWIO (contact C6) 




4 


UICC-^T 


Resume SWP 




5 


T-»UICC 


Send transition sequence 


RQ2, 
RQ15 


6 


UICC^T 


Send ACT SYNC frame 




7 


T^UICC 


Send an ACT_POWER_l\/IODE frame indicating full power mode with FR = 


RQ4, 
RQ16 


8 


UICC 


No frame 




9 


T^ UICC 


Send an ACT_POWER_MODE frame indicating full power mode with FR=1 


RQ8, 
RQ16 


10 


UICC^T 


Send ACT READY frame 




11 


T^ UICC 


Send RSET frame or send a CLT frame 


RQ7 



5.3.2.3.10 Test case 9: SWP initial activation failed in full power mode - corrupted 

ACT_READY frame (multiple) 



5.3.2.3.10.1 



Test execution 



The test procedure shall only be executed in voltage class B, if available, and voltage class C, full power mode, if 
available. 

5.3.2.3.10.2 Initial conditions 

• None of the UICC contacts is activated. 



5.3.2.3.10.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User^T 


Trigger the terminal to activate y^^, SWIO 




2 


T^UICC 


Activate Vcc (contact CI) 




3 


T-^ UICC 


Activate SWIO (contact C6) 




4 


UICC-^T 


Resume SWP 




5 


T^ UICC 


Send transition sequence 


R02, 
RQ15 


6 


UICC-^T 


Send ACT SYNC frame 




7 


T-^ UICC 


Send an ACT POWER IVIODE frame indicating full power mode with FR = 




8 


UICC->T 


Respond with corrupted ACT READY frame 




9 


T^ UICC 


Send an ACT_POWER_IVIODE frame indicating full power mode with FR=1 


R09, 
RQ16 


10 


UICC-^T 


Respond with corrupted ACT READY frame 




11 


T^UICC 


Send an ACT_POWER_IVIODE frame indicating full power mode with FR=1 


R09, 
RQ16 


12 


UICC^T 


Respond with corrupted ACT READY frame 




13 


T^UICC 


Send an ACT_POWER_IVIODE frame indicating full power mode with FR=1 


R09, 
RQ16 


14 


UICC^T 


Respond with corrupted ACT READY frame 




15 


T-^ UICC 


Deactivate SWIO (contact C6) 


RQ10 
RQ11 
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5.3.2.3.11 



5.3.2.3.11.1 



Test case 10: SWP initial activation failed in full power mode - no ACTREADY 
frame (multiple) 

Test execution 



The test procedure shall only be executed in voltage class B, if available, and voltage class C, full power mode, if 
available. 

5.3.2.3.11.2 Initial conditions 

• None of the UICC contacts is activated. 



5.3.2.3.11.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User^T 


Trigger the terminal to activate V^q, SWIO 




2 


T^ UICC 


Activate Vcc (contact CI) 




3 


T^UICC 


Activate SWIO (contact C6) 




4 


UICC-^T 


Resume SWP 




5 


T-^UICC 


Send transition sequence 


RQ2, 
RQ15 


6 


UICC-^T 


Send ACT SYNC frame 




7 


T^UICC 


Send an ACT_POWER_MODE frame indicating full power mode with FR = 


R04, 
RQ16 


8 


UICC 


No frame 




9 


T^ UICC 


Send an ACT_POWER_MODE frame indicating full power mode with FR=1 


R09, 
RQ16 


10 


UICC 


No frame 




11 


T^ UICC 


Send an ACT_POWER_MODE frame indicating full power mode with FR=1 


R09, 
RQ16 


12 


UICC 


No frame 




13 


T^UICC 


Send an ACT_POWER_MODE frame indicating full power mode with FR=1 


RQ9, 
RQ16 


14 


UICC 


No frame 




15 


T^UICC 


Deactivate SWIO (contact C6) 


RQ10, 
RQ11 



5.3.2.3.12 Test case 1 1 : SWP initial activation in low power mode 

5.3.2.3.12.1 Test execution 

The test procedure shall be performed only for voltage class C, low power mode. 

5.3.2.3.12.2 Initial conditions 

• None of the UICC contacts is activated. 
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5.3.2.3.12.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User -^ T 


Trigger the terminal to activate V^;,, SWIO and to perform further 

communication over SHDLC or CLT (for example, by initiating a contactless 
card emulation session as specified in TS 102 622 [4]) 




2 


T^ UICC 


Activate Vcc (contact C1 ) 




3 


T^UICC 


Activate SWIO (contact 06) 




4 


UICC^T 


Resume SWP 




5 


T->UICC 


Send transition sequence 


RQ2, 
RQ15 


6 


UICC^T 


Send ACT SYNC frame 




7 


T^UICC 


Send RSET frame or send a CLT frame 


RQ3 


NOTE: RQ 1 8 applies to all steps. 



5.3.2.3.13 Test case 12:SWP initial activation in low power mode - corrupted ACTSYNC 

frame (repeat the last frame) 

5.3.2.3.13.1 Test execution 

The test procedure shall be performed only for voltage class C, low power mode. 

5.3.2.3.13.2 Initial conditions 

• None of the UICC contacts is activated. 



5.3.2.3.13.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User -> T 


Trigger the terminal to activate V^q, SWIO and to perform further 
communication over SHDLC or CLT (for example, by initiating a contactless 
card emulation session as specified in TS 1 02 622 [4]) 




2 


T^UICC 


Activate Vcc (contact 01) 


RQ18 


3 


T^ UICC 


Activate SWIO (contact 06) 




4 


UICC^T 


Resume SWP 




5 


T^ UICC 


Send transition sequence 


R02, 
RQ15 


6 


UICC^T 


Send corrupted ACT SYNC frame 




7 


T^ UICC 


Send an ACTPOWERMODE frame indicating low power mode with FR=1 


R05, 
RQ16, 
RQ23, 
RQ25, 
RQ26, 
RQ27, 
RQ29 


8 


UICC^T 


Send ACT SYNC frame 




9 


T^ UICC 


Send RSET frame or send a CLT frame 


R06 



5.3.2.3.14 Test case 13: SWP initial activation in low power mode - no ACTSYNC frame 

(repeat the last frame) 

5.3.2.3.14.1 Test execution 

The test procedure shall be performed only for voltage class C, low power mode. 

The test procedure shall be performed with variation in the parameters T52 act RES V '^^'^ ^82 ACT FRP' ^^ following 
values and combinations: 

• Ts2 ACT RES V between 10 |is and 50 |is; T52 act frp between 1 950 |is and 2 000 |is. 



£75/ 



Release 9 



37 



ETSI TS 102 694-1 V9.2.0 (2013-04) 



• ''^82 ACT RES V between 650 |is and 700 |is; Tg2 act frp between |is and 50 ]xs. 

5.3.2.3.14.2 Initial conditions 

• None of the UICC contacts is activated. 



5.3.2.3.14.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate W^^, SWIO and to perform further 
communication over SHDLC or CLT (for example, by initiating a contactless 
card emulation session as specified in TS 1 02 622 [4]) 




2 


T^UICC 


Activate Vcc (contact CI) 


RQ18 


3 


T^ UICC 


Activate SWIO (contact C6) 




4 


UICC^T 


Resume SWP 




5 


T^ UICC 


Send transition sequence 


R02, 
RQ15 


6 


UICC 


No frame (set S2 to state L within 4 idle bits) 




7 


T^UICC 


Send an ACTPOWER MODE frame indicating low power mode with FR=1 


RQ5, 
RQ16 


8 


UICC^T 


Send ACT SYNC frame 




9 


T^UICC 


Send RSET frame or send a CLT frame 


R06 



5.3.2.3.15 Test case 14: SWP initial activation failed in low power mode - corrupted 

ACT_SYNC frame (multiple) 

5.3.2.3.15.1 Test execution 

The test procedure shall be performed only for voltage class C, power mode. 

5.3.2.3.15.2 Initial conditions 

• None of the UICC contacts is activated. 



5.3.2.3.15.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User -» T 


Trigger the terminal to activate V^q, SWIO 




2 


T^ UICC 


Activate Vcc (contact CI) 


RQ18 


3 


T->UICC 


Activate SWIO (contact C6) 




4 


UICC->T 


Resume SWP 




5 


T^UICC 


Send transition sequence 


R02, 
RQ15 


6 


UICC ^ T 


Send corrupted ACT SYNC frame 




7 


T^UICC 


Send an ACT_POWER_IVIODE frame indicating low power mode with FR=1 


R05, 
RQ16 


8 


UICC^T 


Send corrupted ACT SYNC frame 




9 


T^ UICC 


Send an ACT_POWER_IVIODE frame indicating low power mode with FR=1 


ROB, 
RQ16 


10 


UICC^T 


Send corrupted ACT SYNC frame 




11 


T-^ UICC 


Send an ACT_POWER_IVIODE frame indicating low power mode with FR=1 


ROB, 
RQ16 


12 


UICC-»T 


Send corrupted ACT SYNC frame 




13 


T-> UICC 


Deactivate SWIO (contact C6) 


RQ10, 
RQ11 
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Test case 1 5: SWP initial activation failed in low power mode - no ACTSYNC 
frame (multiple) 



5.3.2.3.16.1 Test execution 

The test procedure shall be performed only for voltage class C, low power mode. 

5.3.2.3.16.2 Initial conditions 

• None of the UICC contacts is activated. 



5.3.2.3.16.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate V^q, SWIO 




2 


T^ UICC 


Activate Vcc (contact CI) 


RQ18 


3 


T^UICC 


Activate SWIO (contact C6) 




4 


UICC^T 


Resume SWP 




5 


T^UICC 


Send transition sequence 


R02, 
RQ15 


6 


UICC 


No frame (set S2 to state L within 4 idle bits) 




7 


T->UICC 


Send an ACT_POWER_IVIODE frame indicating low power mode with FR=1 


R05, 
RQ16 


8 


UICC 


No frame 




9 


T^ UICC 


Send an ACTPOWERMODE frame indicating low power mode with FR=1 


R09, 
RQ16 


10 


UICC 


No frame 




11 


T^ UICC 


Send an ACT_POWER_MODE frame indicating low power mode with FR=1 


R09, 
RQ16 


12 


UICC 


No frame 




13 


T^UICC 


Deactivate SWIO (contact C6) 


RQ10, 
RQ11 



5.3.2.3.17 



5.3.2.3.17.1 



Test case 16: SWP subsequent activation in full power mode 



Test execution 



The test procedure shall only be executed in voltage class B, if available, and voltage class C, full power mode, if 
available. 

The test procedure shall be executed once for each of following parameters: 

• Ts2 ACT RES D between 10 |is and 50 |is. 

• ^S2 ACT RES D between 400 us and 500 us. 



5.3.2.3.17.2 



Initial conditions 



The SWP resides in DEACTIVATED state, and previously an initial SWP interface activation has been 
successful. 
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5.3.2.3.17.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate SWIO and to perform further communication 
over SHDLC or CLT (for example, by initiating a contactless card emulation 
session as specified in TS 102 622 [4]) 




2 


T^UICC 


Perform subsequent SWP interface activation (see note) 


RQ13 
RQ20, 
RQ24 


3 


UICC^T 


Resume SWP 




4 


T^UICC 


Send transition sequence 


RQ2, 
RQ17 


5 


UICC-^T 


Send ACT SYNC frame 




6 


T-»UICC 


Send RSET frame or send a CLT frame 


RQ14 



5.3.2.3.18 



Void 



5.3.2.3.19 



5.3.2.3.19.1 



Test case 18: SWP initial activation in full power mode - send ACT frames in 
wrong order, ACTREADY frame after activation (repeat the last frame) 

Test execution 



The test procedure shall only be executed in voltage class B, if available, and voltage class C, full power mode, if 
available. 

5.3.2.3.19.2 Initial conditions 

• None of the UICC contacts is activated. 



5.3.2.3.19.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User -» T 


Trigger the terminal to activate V^^, SWIO and to perform further 
communication over SHDLC or CLT (for example, by initiating a contactless 
card emulation session as specified in TS 1 02 622 [4]) 




2 


T^UICC 


Activate Vcc (contact C1) 




3 


T^UICC 


Activate SWIO (contact C6) 




4 


U1CC->T 


Resume SWP 




5 


T^UICC 


Send transition sequence 


R02, 
RQ15 


6 


UICC-»T 


Send ACT READY frame 




7 


T^ UICC 


Send an ACT_POWER_MODE frame indicating full power mode with FR=1 


RQ12, 
RQ16 


8 


UICC-»T 


Send ACT SYNC frame 




9 


T^ UICC 


Send RSET frame or send a CLT frame 


R06 



5.3.2.4 



Behavior of a UICC in a terminal not supporting SWP 



5.3.2.4.1 Conformance requirements 

Reference: TS 102 613 [1], clause 6.2.4. 
There are no conformance requirements for the terminal for the referenced clause. 
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5.3.2.5 Behavior of terminal connected to a UICC not supporting SWP 

5.3.2.5.1 Conformance requirements 

Reference: TS 102 613 [1], clause 6.2.5. 
All conformance requirements for the referenced clause are included in clause 5.3.2.3 of the present document. 

5.3.2.5.2 Void 

5.3.2.6 Inactive contacts 
5.3.2.6.1 Conformance requirements 

Reference: TS 102 613 [1], clause 6.2.6. 



RQ1 [The conditions for inactive contacts as defined in TS 1 02 221 [2] shall apply to contact C6. 



NOTE: There is no explicite test case for RQ1 in the present document (fully covered by other test cases). 



5.4 Electrical characteristics 

5.4.1 Operating conditions and sub-clauses 

5.4.1.1 Operating conditions 

Reference: TS 102 613 [1], clause 7.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.4.1.2 Supply voltage classes 

Reference: TS 102 613 [1], clause 7.1.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.4.1 .3 Vcc(C1 ) low power mode definition 
5.4.1.3.1 Conformance requirements 

Reference: TS 102 613 [1], clause 7.1.2. 



RQ1 



A terminal shall provide a supply voltage Vqq in the range 1 ,62 V to 1 ,98 V. 



RQ2 



A terminal shall maintain Vqq in the specified range despite transient power consumption (spikes on Iqq) 
of maximum 6 nAs. The maximum duration of these spikes shall be 400 ns and their maximum variation 
shall be 30 mA. 



RQ3 



A terminal shall provide a minimum current Iqq of 5 mA. The current value is averaged over a period of 
1 ms. 
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Test case 1 : current provided in low power mode, no spikes 



5.4.1.3.2.1 Test execution 

The test procedure shall only be executed in voltage class C, low power mode. 
The test procedure shall apply for the following parameters: 

• UICC's current consumption is 5 mA (after activation of contact V^^^). 

• UICC's current consumption is mA (after activation of contact Vqj;;). 

5.4.1.3.2.2 Initial conditions 

• None of the UICC contacts is activated. 



5.4.1.3.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User-^T 


Trigger the terminal to activate contact Vqq and contact SWIO in low power mode 
and to perform further communication over SHDLC or CLT (for example, by 
initiating a contactless card emulation session as specified in TS 102 622 [4]) 




2 


T^UICC 


Activate Vcc (contact C1 ) 


RQ1, 
RQ3 


3 


T^UICC 


Activate SWIO (contact C6) 


RQ1, 
RQ3 


4 


UICC^^T 


Perform initial SWP interface activation (low power mode) 


RQ1, 
RQ3 


5 


T^^ UICC 


Perform SHDLC link establishment or send a CLT frame 


RQ1, 
RQ3 



5.4.1.3.3 



Test case 2: current provided in low power mode, with spikes 



5.4.1.3.3.1 Test execution 

The test procedure shall only be executed in voltage class C, low power mode. 

The test procedure shall apply for the following parameters: 

• After activation of contact Vcc, the UICC's current consumption shall be varied with following spike profiles: 
random spikes: 

■ current amplitude 10 mA; 

■ current offset mA; 

■ duration 400 ns; 

■ pause between 0, 1 ms and 500 ms, randomly varied, 
random spikes: 

■ current amplitude 30 mA; 

■ current offset mA; 

■ duration 200 ns; 

■ pause between 0, 1 ms and 500 ms, randomly varied. 
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5.4.1.3.3.2 



random spikes: 

■ current amplitude 30 mA; 

■ current offset 4,9 mA; 

■ duration 200 ns; 

■ pause between 0, 1 ms and 500 ms, randomly varied, 
random spikes: 

■ current amplitude 30 mA; 

■ current offset mA; 

■ duration 100 ns; 

■ pause between 0, 1 ms and 500 ms, randomly varied, 
random spikes: 

■ current amplitude 30 mA; 

■ current offset 4.9 mA; 

■ duration 100 ns; 

■ pause between 0, 1 ms and 500 ms, randomly varied. 

Initial conditions 



None of the UlCC contacts is activated. 



5.4.1.3.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate contact y^^ and contact SWIO in low power 
mode 




2 


T^UICC 


Activate Vcc (contact CI) 


RQ1, 
RQ2, 
RQ3 


3 


T^ UlCC 


Activate SWIO (contact C6) 


RQ1, 
RQ2, 
RQ3 


4 


UlCC ^^ T 


Perform initial SWP interface activation (low power mode) and SHDLC link 
establishment 


RQ1, 
RQ2, 
RQ3 


5 


T^^UICC 


Run the representative SWP frame exchange procedure 


RQ1, 
RQ2, 
RQ3 
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5.4.1.4 



Signal S1 



5.4.1.4.1 Conformance requirements 

Reference: TS 102 613 [1], clause 7.1.3. 



RQ1 



In voltage class B, the terminal output voltage on SWIO with SI in state H (Vq|_|) shall be in the range of 
1 ,40 V to 1 .98 V (see note 1 ). This range shall be maintained for currents between [xA and 1 OOP |iA. 



RQ2 



In voltage class B, the terminal output voltage on SWIO with S1 in state L (Vq^) shall be in the range of 
V (see note 3) to 0,3 V. This range shall be maintained for currents between [xA and -20 pA. 



RQ3 



In voltage class C, the terminal output voltage on SWIO with S1 in state H (Vq^) shall be in the range of 
0,85 X Vqq to Vqq (see note 2). This range shall be maintained for currents between |jA and 1 000 |jA. 



RQ4 



In voltage class C, the terminal output voltage on SWIO with S1 in state L (VqJ shall be in the range of 
V (see note 3) to 0,15 x Vqq. This range shall be maintained for currents between |iA and -20 |jA. 



NOTE 1 : The upper limit of S1 (1 .98 V) is extended to Vq|_| ^^^ + 0,3V (applying the values defined for dynamic 

operation in TS 102 613 [1] to all periods). 
NOTE 2: The upper limit of SI (Vqq) is extended to \/qq + 0,3V (applying the values defined for dynamic 

operation in TS 102 613 [1] to all periods). 
NOTE 3: The lower limit of SI (0 V) is extended to -0,3 V (applying the values defined for dynamic operation in 
TS 102 613 [1] to all periods). 



5.4.1.4.2 



Test case 1 : communication with S2 variation in full power mode 



5.4.1.4.2.1 Test execution 

The test procedure shall only be executed in voltage class C and voltage class B if available in full power mode. 
The test procedure shall be executed once for each of following parameters: 

• Load current for SI in state H, S2 signal: State L |i A/state H 1 000 |iA. 

• Load current for S 1 in state L: -20 |i A. 

5.4.1.4.2.2 Initial conditions 

• None of the UlCC contacts is activated. 



5.4.1.4.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate contact V(,(, and contact SWIO and to perform 
further communication over SHDLC or CLT (for example, by initiating a 
contactless card emulation session as specified in TS 1 02 622 [4]) 




2 


T^ UlCC 


Activate Vcc (contact CI) 




3 


T^ UlCC 


Activate SWIO (contact C6) 


R01, 
R02, 
R03, 
R04 


4 


UlCC ^^ T 


Perform initial SWP interface activation 


R01, 
R02, 
R03, 
R04 


5 


T^^UICC 


Perform SHDLC link establishment or send a CLT frame 


R01, 
R02, 
R03, 
R04 
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5.4.1.4.3 



Test case 2: communication with S2 variation in low power mode 



5.4.1.4.3.1 Test execution 

The test procedure shall only be executed in voltage class C, low power mode. 
The test procedure shall be executed once for each of following parameters: 

• Load current for SI in state H, S2 signal: State L |i A/state H 1 000 |iA. 

• Load current for S 1 in state L: -20 |i A. 

5.4.1 .4.3.2 Initial conditions 

• None of the UICC contacts is activated. 



5.4.1.4.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User^T 


Trigger the terminal to activate V(,(, and SWIO in low power mode and to perform 

further communication over SHDLC or CLT (for example, by initiating a contactless 
card emulation session as specified in TS 102 622 [4]) 




2 


T-»UICC 


Activate Vcc (contact C1 ) 




3 


T-»UICC 


Activate SWIO (contact C6) 


RQ3, 
RQ4 


4 


UICC^T 


Perform initial SWP interface activation (low power mode) 


RQ3, 
RQ4 


5 


14-^ UICC 


Perform SHDLC link establishment or send a CLT frame 


RQ3, 
RQ4 



5.4.1.5 



Signal S2 and subclauses 



5.4.1.5.1 Signal S2 

Reference: TS 102 613 [1], clause 7.1.4. 
There are no conformance requirements for the terminal for the referenced clause. 



5.4.1.5.2 



Operating current for S2 



5.4.1.5.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 7.1.4.1. 



RQ1 



In voltage class B and with SI in the range between 1,13V and 2,28 V, the terminal shall consider state 
H when the UICC draws a current between 600 mA and 1 OOP |iA 



RQ2 



In voltage class B and with SI in the range between 1,13V and 2,28 V, the terminal shall consider state 
L when the UICC draws a current between [xA and 20 [xA 



RQ3 



In voltage class C and with SI in the range between 0,7 x Vqq and Vqq + 0,3 V, the terminal shall 
consider state H when the UICC draws a current between 600 |jA and 1 OOP [xA 



RQ4 



In voltage class C and with SI in the range between 0,7 x V^q and Vqq + 0,3 V, the terminal shall 
consider state L when the UICC draws a current between P [xA and 2P ^A 
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Test case 1 : communication witin S2 variation in full power mode 



5.4.1 .5.2.2.1 Test execution 

The test procedure shall only be executed in voltage class C and voltage class B if available in full power mode. 
The test procedure shall be executed once for each of following parameters: 

• S2 signal: State L 20 |iA/state H 600 |iA. 

5.4.1 .5.2.2.2 Initial conditions 

• None of the UICC contacts is activated. 



5.4.1.5.2.2.3 



Test Procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate y^^ and SWIO and to perform further 
communication over SHDLC or CLT (for example, by initiating a contactless 
card emulation session as specified in TS 102 622 [4]) 




2 


T^UICC 


Activate Vcc (contact C1) 




3 


T^UICC 


Activate SWIO (contact C6) 


RQ1, 
RQ2, 
RQ3, 
RQ4 


4 


UICC^ ^T 


Perform initial SWP interface activation 


RQ1, 
RQ2, 
RQ3, 
RQ4 


5 


T^ ^ UICC 


SHDLC link establishment or send a CLT frame 


RQ1, 
RQ2, 
RQ3, 
RQ4 



5.4.1 .5.2.3 Test case 2: communication with S2 variation in low power mode 

5.4.1 .5.2.3.1 Test execution 

The test procedure shall only be executed in voltage class C, low power mode. 
The test procedure shall be executed once for each of following parameters: 

• S2 signal: State L 20 |iA/state H 600 |iA. 

5.4.1.5.2.3.2 Initial conditions 

• None of the UICC contacts is activated. 



5.4.1.5.2.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate V(,(, and SWIO in low power mode and to 
perform further communication over SHDLC or CLT (for example, by initiating 
a contactless card emulation session as specified in TS 102 622 [4]) 




2 


T^ UICC 


Activate Vcc (contact C1) 




3 


T^UICC 


Activate SWIO (contact C6) 


RQ3, 
RQ4 


4 


UICC^T 


Perform initial SWP interface activation (low power mode) 


RQ3, 
RQ4 


5 


T^ ^ UICC 


SHDLC link establishment or send a CLT frame 


RQ3, 
RQ4 
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5.5 Physical transmission layer 
5.5.1 S1 Bit coding and sampling time 
5.5.1.1 Conformance requirements 

Reference: TS 102 613 [1], clause 8.1; additional clause 3.1 for RQ12. 



RQ1 


When sending a bit on S1 witli the logical value and the bit duration T, the terminal shall apply a 
leading rising edge to state H, maintain S1 in state high for a time T|_|g with the minimum of 0,20 x T 

and the maximum of 0,30 x T, then apply a falling edge to state L, then apply a trailing rising edge to 
state H after T. The timing reference point for T and T^q shall be 50 % of the S1 signal amplitude. 


RQ2 


When sending a bit on S1 with the logical value 1 and the bit duration T, the terminal shall apply a 
leading rising edge to state H, maintain S1 in state high for a time T^., with the minimum of 0,70 x T 

and the maximum of 0,80 x T, then apply a falling edge to state L, then apply a trailing rising edge to 
state H after T. The timing reference point for T and T^^ shall be 50 % of the S1 signal amplitude. 


RQ3 


When sending a bit on S1 with the bit duration T in the range of 0,590 |as < T < 5,0 |is, the rise time of 
the S1 signal for both the leading and the trailing rising edge shall be in the range tr with a minimum of 
5 ns and a maximum of 0,05 x T, where the timing reference points for the rise time are 10 % and 90 % 
of the signal amplitude. 


RQ4 


When sending a bit on S1 with the bit duration T in the range of greater than 5,0 us < T < 1 0,0 |is, the 
rise time of the SI signal for both the leading and the trailing rising edge shall be in the range tr with a 
minimum of 5ns and a maximum of 250 ns, where the timing reference points for the rise time are 1 % 
and 90 % of the signal amplitude. 


RQ5 


When sending a bit on SI with the bit duration T in the range of 0,590 |as < T < 5,0 |is, the fall time of 
the SI signal shall be in the range tf with a minimum of 5 ns and a maximum of 0,05 x T, where the 
timing reference points for the fall time are 1 % and 90 % of the signal amplitude. 


RQ6 


When sending a bit on SI with the bit duration T in the range of 5,0 us < T < 1 0,0 \as, the fall time of the 
S1 signal shall be in the range tf with a minimum of 5ns and a maximum of 250 ns, where the timing 
reference points for the fall time are 10 % and 90 % of the signal amplitude. 


RQ7 


Before the CLF has received an ACT_SYNC frame during initial interface activation, it shall only send 
bits with a default bit duration T. 


RQ8 


Void. 


RQ9 


After the CLF has received an ACT_SYNC frame during initial interface activation, it shall only send 
bits with a duration T within the limits indicated in the ACT_IN FORMATION field; this applies until Vcc 
is deactivated. 


RQ10 


For a transition from DEACTIVATED state or for SWIO contact activation (proceeding the SWP 
interface activation procedure), the terminal shall apply a rise time tr of the signal SI in the range of 5 
ns to 250 ns. 


RQ11 


For a transition to DEACTIVATED state, the terminal shall apply a fall time tf of the signal SI in the 
range of 5 ns to 250 ns. 


RQ12 


When sending a transition sequence, consisting of the falling edge, the state L period and the rising 
edge of an idle bit, the definitions as described in RQ3, RQ4, RQ5, RQ6 for the fall time tf for the 
leading edge and the rise time tr for the trailing edge shall apply. The value of T shall result from the 
length of the state L period, where the timing reference point shall be 50 % of the S1 signal amplitude. 


NOTE: Test cases for RQ10 are given in clause 5.3.2.3.17. 



5.5.1.2 



Test case 1 : 81 waveforms, default bit duration 



5.5.1 .2.1 Test execution 

The test procedure shall be executed for the following parameters: 
• S2 signal, Ijj = 1 000 ^A, S2 signal, II = ^A. 

In case the terminal provides means to be configured for certain bit rate ranges on S 1 (and this information is provided 
by the DUT manufacturer), the test procedure shall be performed with variation to the minimum and the maximum bit 
duration within the bit duration range supported, for frame exchange in the ACT LLC or the SHDLC LLC, or both. 
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5.5.1.2.3 



5.5.1.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User-^T 


Trigger the terminal to activate Vcc (contact CI ) and SWIO (contact C6), and 
SWP interface activation in the requested power mode 




2 


T^UICC 


Activate Vcc (contact CI ) 




3 


T^UICC 


Activate SWIO (contact C6) (see note) 


RQ10 


4 


UICC ^T 


Resume SWP 




5 


T^UICC 


Send transition sequence 


RQ12 


6 


UICC^T 


Send ACT_SYNC frame, with ACT_INFORIVIATION field indicating that 
extended bit durations are not supported 


RQ1, 
RQS, 
RQS 
RQ7 


7 


T^^ UICC 


If the terminal performs initial SWP interface activation in full power mode, 
complete initial SWP interface activation 


RQ1, 
RQ2, 
RQS, 
RQS, 
RQ9 


8 


T^ ^UICC 


Perform SHDLC link establishment 


RQ1, 
RQ2, 
RQS, 
RQS, 
RQ9 


9 


UICC ^ ^ T 


Run the representative SWP frame exchange procedure 

The frame exchange shall be performed in such a way, that the referenced 
RQs can be fully validated. The procedure shall contain full-duplex 
communication, where the crossover combination of bits with "SI = logical 1 
/ S2 = logical 1 " shall occur at least 20 times. Since the occurrence of 
situations related to RQ1 2 depends on the terminal implementation, non- 
occurrence of these situations shall not lead to a fail of this step 


RQ1, 
RQ2, 
RQS, 
RQS, 
RQ9, 
RQ12 


10 


User^T 


Trigger the terminal to put SWP into DEACTIVATED state 




11 


T^UICC 


Put SWP into DEACTIVATED state 


RQ11 



Test case 2: SI waveforms, extended bit durations 



5.5.1.3.1 Test execution 

The test procedure shall be executed once for each of the following parameters: 

• S2 signal, I^ = 1 000 ^A, S2 signal, II = ^A. 

In case the terminal provides means to be configured for certain bit rate ranges on S 1 (and this information is provided 
by the DUT manufacturer), the test procedure shall be performed with variation to the minimum and the maximum bit 
duration within the bit duration range supported, for frame exchange in the ACT LLC or the SHDLC LLC, or both. 

5.5.1.3.2 Initial conditions 

• None of the UICC contacts is activated. 
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5.5.1.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate Vcc (contact CI) and SWIO (contact C6), and 
SWP interface activation in the requested power mode 




2 


T^UICC 


Activate Vcc (contact CI) 




3 


T^ UICC 


Activate SWIO (contact C6) (see note) 


RQ10 


4 


UICC^T 


Resume SWP 




5 


T^ UICC 


Send transition sequence 


RQ12 


6 


UICC ^ T 


Send ACT_SYNC frame, with ACTJNFORMATION field indicating bit 
durations supported down to 0,590 \is and up to 10 |as 


RQ1, 
RQ3, 
RQS 
RQ7 


7 


T^^UICC 


If the terminal performs initial SWP interface activation in full power mode, 
complete initial SWP interface activation 


RQ1, 
RQ2, 
RQ3, 
RQ4, 
RQS, 
RQ6, 
RQ9 


8 


T^ ^ UICC 


Perform SHDLC link establishment 


RQ1, 
RQ2, 
RQ3, 
RQ4, 
RQS, 
RQ6, 
RQ9 


9 


UICC^ ^T 


Run the representative SWP frame exchange procedure 

The frame exchange shall be performed in such a way, that the referenced 
RQs can be fully validated. The procedure shall contain full-duplex 
communication, where the crossover combination of bits with "SI = logical 1 
/ S2 = logical 1" shall occur at least 20 times. Since the occurrence of 
situations related to RQ1 2 depends on the terminal implementation, non- 
occurrence of these situations shall not lead to a fail of this step 


RQ1, 
RQ2, 
RQ3, 
RQ4, 
RQS, 
RQ6 
RQ9, 
RQ12 


10 


User ^ T 


Trigger the terminal to put SWP into DEACTIVATED state 




11 


T^ UICC 


Put SWP into DEACTIVATED state 


RQ11 



5.5.2 S2 switching management 
5.5.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 8.2. 
There are no conformance requirements for the terminal for the referenced clause. 
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5.5.3 SWP interface states management 
5.5.3.1 Conformance requirements 

Reference: TS 102 613 [1], clause 8.3. 



RQ1 




For a transition from SWP SUSPENDED state to SWP DEACTIVATED state, the terminal shall maintain 
S1 in state L for at least P4 = 1 00 [is. 


RQ2 




For a transition from SWP ACTIVATED state to SWP SUSPENDED state, the terminal shall issue at least 
P1 = 7 idle bits on S1 . If there are only idle bits on S2, the SWP SUSPENDED state shall be valid after 
maintaining SI in state H. 


RQ3 




If the terminal has not received an upper layer indication that the UICC requires no more activity on this 
interface, the terminal shall resume by sending a transition sequence consisting of the state L period of an 
idle bit. Then the terminal shall issue idle bits on SI . After subsequent P2 = 8 idle bits, and if there are no 
other than idle bits on S2, the SWP state ACTIVATED shall be valid. 


RQ4 




When the terminal resumes the SWP, the terminal shall issue a transition sequence consisting of the 
falling edge, the state L period and the rising edge of an idle bit. Then the terminal shall issue at least P2 
= 8 idle bits on SI . The terminal shall be capable of receiving bits sent by the UICC during the P2 idle bits. 


RQ5 




When SWP resides in SUSPENDED state, and the slave resumes by drawing a current (S2 in state H), 
within P3 < 5 MS the terminal shall issue a transition sequence consisting of the state L period of an idle 
bit. At the end of the transition sequence the SWP state ACTIVATED shall be valid. 


RQ6 




Subsequently to the procedure as described in RQ5, the terminal shall accept SOF sent by the slave after 
a delay of to 4 bits after the transition sequence. Following S2 pattern shall be considered as valid: 

W=R/T| 1st bit of SOF 
R/T|W|1stbitofSOF 
R/T|X| W| IS' bit of SOF 
R/T|X|X|W| IstbitofSOF 
R/T|X|X|X|W|1stbitofSOF. 

Where R is the slave resume, W the wakeup sequence, T is the transition sequence, X represents either 
orl. 


RQ7 




The CLF shall be capable of receiving frames in the ACTIVATED state. 


RQ8 




If the terminal has received an upper layer indication that the UICC requires no more activity on this 
interface then the terminal resumes by operating a SWIO deactivation and SWIO activation. 


RQ9 




The terminal may switch from SWP SUSPENDED to the DEACTIVATED state if the UICC has indicated 
on a higher layer that no more activity is required on this interface. 


RQ10 




The terminal may switch from SWP SUSPENDED to the DEACTIVATED state if the SWP is in 
SUSPENDED state for a time of P5 = 1 5 ms and the CLF either does not detect an RF field compliant 
with ISO/IEC 14443-2 [10] or ISO/IEC 18092 [8]; or does not generate an RF field on request from the 
UICC. 


RQ11 


Rel-9 


The terminal shall respond by sending a transition sequence in less than P6= 20 ms if all the following 
conditions are met: 

- the UICC has indicated support of extended resume (see clause 9.4); and 

- the last information the terminal has received is an indication via an upper layer that the UICC 

requires no more activity on this interface; and 

- the SWP is in SUSPENDED state for at least a time of P7 = 20 ms. 

Else the terminal shall respond by sending a transition sequence in less than P3max time. 


NOTE 1 : Further conformance requirements for TS 1 02 61 3 [1 ], clause 8.3, are listed in clause 5.3.2.3. 
NOTE 2: How to test for R08, R09 and R01 is FFS. 
NOTE 3: Development of test cases for RQ1 1 is FFS. 



5.5.3.2 Test case 1 : SWP states and transitions, communication 

5.5.3.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.5.3.2.2 Initial conditions 

• None of the UICC contacts is activated. 
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5.5.3.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate Vcc (contact CI) and SWIO (contact C6), and 
SWP interface activation in the requested power mode 




2 


T^UICC 


Activate Vcc (contact CI) 




3 


T^ UICC 


Activate SWIO (contact C6) (see note) 




4 


UICC^T 


Resume SWP 




5 


T^ UICC 


Send transition sequence 


R05 


6 


UICC-»T 


Send ACT_SYNC frame, with ACTJNFORMATION field indicating bit 
durations supported down to 0,590 [is and up to 10 [xs 


R06, 
R07 


7 


T^ -^ UICC 


If the terminal performs initial SWP interface activation in full power mode, 
complete initial SWP interface activation 


R07 


8 


T^ ^ UICC 


Perform SHDLC link establishment 


R07 


9 


UICC^ ^T 


Run the representative SWP frame exchange procedure 

The frame exchange shall be performed in such a way, that the referenced 
RQs can be fully validated. Since the occurrence of situations related to 
RQ3, RQ4, RQS, RQ6 and RQ7 depends on the terminal implementation, 
non-occurrence of these situations shall not lead to a fail of this step 

When validating the last part of RQ4 (sending a frame during the P2 idle bits 
after a terminal resume), the UICC simulator shall ensure that each of the 
following scenarios occurs at least once (where W is the wakeup sequence): 

• The UICC sends a frame with W at the 1 " P2 idle bit. 

• The UICC sends a frame with W at the 4* P2 idle bit. 

• The UICC sends a frame with W at the 8* P2 idle bit. 

When validating R06, the UICC simulator shall apply each of the following 
S2 patterns at least once: 

. W=R/T| IstbitofSOF 

. R/T| W|1stbitof SOP 

. R/T| 1 1 W| IstbitofSOF 

. R/T|0|0|W|1stbitofSOF. 

• R/T|0|0|0|W| Istbitof SOF. 


R02, 
RQ3, 
RQ4, 
RQS 
RQ6 
RQ7 


10 


User -> T 


Trigger the terminal to put SWP into DEACTIVATED state 




11 


T 


SWP in SUSPENDED state 


RQ2 


12 


T^ UICC 


Put SWP into DEACTIVATED state 


RQ1 


NOTE: SWP in SUSPENDED state. 



5.5.4 Power mode states/transitions and Power saving mode 



5.5.4.1 Conformance requirements 

Reference: TS 102 613 [1], clause 8.4. 



RQ1 



The CLF shall indicate full power mode if sufficient power from the terminal's power supply (e.g. battery) 
is available. 



RQ2 



The terminal shall provide sufficient power for the UICC in low power mode. 



RQ3 



The terminal shall provide sufficient power for the UICC in full power mode. 



RQ4 



The terminal shall not switch from full power mode to low power mode or vice versa without deactivation 
of Vcc. 



NOTE: Test cases for RQ2 are given in clause S.4.1 .3 (V(,(,(C1 ) low power mode definition). 
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5.5.4.2 



Test case 1 : power provided in full power mode 



5.5.4.2.1 



Test execution 



The test procedure shall only be executed in voltage class B, if available, and voltage class C, full power mode, if 
available. 

During the test procedure, for each power mode/state the UICC shall vary the current drawn between mA and the 
maximum current specified for the terminal to be delivered in this particular power mode/state. 

5.5.4.2.2 Initial conditions 

• None of the UICC contacts is activated. 

• The terminal's power supply provides sufficient power for full power mode operation. 



5.5.4.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate V^q (contact C1) and SWIO (contact C6), 
and SWP interface activation in full power mode 




2 


T^UICC 


Activate Vcc (contact C1) 




3 


T^UICC 


Activate SWIO (contact C6) (see note 2) 


R03 


4 


UICC^T 


Resume SWP 


R03 


5 


T-»UICC 


Send transition sequence 


R03 


6 


UICC ^ T 


Send ACT SYNC frame 


R03 


7 


T^UICC 


Send ACT_POWER_IVIODE frame (full power mode) (see note 1 ) 


R01 
R03 


8 


UICC^T 


Respond ACT READY frame 


R03 


9 


T^ ^ UICC 


Perform SHDLC link establishment 


R03 


10 


UICC^ ^T 


Run the representative SWP frame exchange procedure 


R03 


NOTE 1 : UICC power consumption for full power mode applies. 

NOTE 2: Full power mode applies if one of the other UICC interfaces is activated. 



5.5.4.3 Test case 2: switching from full to low power mode 



5.5.4.3.1 



Test execution 



The test procedure shall be executed in voltage class B, if available, and voltage class C, full power mode, if available, 
each in combination with voltage class C, low power mode. 

5.5.4.3.2 Initial conditions 

• Initial SWP interface activation in full power mode was successfully performed. 

• The terminal's power supply provides sufficient power for full power mode operation. 

5.5.4.3.3 Test procedure 



step 


Direction 


Description 


RQ 


1 


User -^ T 


Change the terminal's power supply condition to provide sufficient power for 
low power mode, but not sufficient power for full power mode operation 




2 


T^ UICC 


The Terminal deactivate V^q 

Upon reactivating V^q, the Terminal does not send the 

ACT POWER IVIODE frame 


R04 
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5.5.4.4 Test case 3: switching from low to full power mode 



5.5.4.4.1 



Test execution 



The test procedure shall be executed in voltage class B, if available, and voltage class C, full power mode, if available, 
each in combination with voltage class C, low power mode. 

5.5.4.4.2 Initial conditions 

• Initial SWP interface activation in low power mode was successfully performed. 

• The terminal's power supply provides sufficient power for low power mode operation, but not for full power 
mode operation. 



5.5.4.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Change the terminal's power supply condition to provide sufficient power for 
full power mode 




2 


T^ UICC 


The Terminal deactivate Mqq 

Upon reactivating Vqq, the Terminal sends the ACT_P0WER_IV10DE frame 


RQ4 



5.6 Data link layer 



5.6.1 Overview 

Reference: TS 102 613 [1], clause 9.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.2 IVIedium Access Control (IVIAC) layer 
5.6.2.1 Bit order 

5.6.2.1.1 Conformance requirements 

Reference: TS 102 613 [1], clause 9.2.1. 



RQ1 The CLF shall send payload data with MSB first. 



RQ2 [The CLF shall interpret payload data received from the UICC with MSB first. 



NOTE: RQ1 and RQ2 are validated implicitly in other testcases within the present document. 
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5.6.2.2 



Structure 



5.6.2.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 9.2.2. 



RQ1 



The CLF shall correctly interpret error free frames sent by UICC with at least one idle bit between the 
frames. 



RQ2 



Between frames, idle bits (logical value 0) are sent. There is at least one idle bit between frames. 



RQ3 



The master shall accept a wakeup sequence, consisting of a bit with logical value 1 inserted before each 
frame sent from the slave. 



RQ4 



The CLF shall reject incorrectly formed frames sent by UICC. 



RQ5 [The CLF shall send only correctly formed frames to the UICC. 



NOTE 1 
NOTE 2 
NOTES 



RQ2 is tested in clause 5.7.7.5.2. 

RQ3 is validated implicitly in other testcases within the present document. 

Part of RQ1 (related to idle bits between frames) is tested in clause 5.7.7.5. 



The following conformance requirement is referenced to TS 102 613 [1], clause 9.2.1.4. 



RQ6 



The CLF shall detect errors on the received frame using the 16 bit frame checking sequence as given in 
ISO/IEC 13239 [9] on bits between SOF and EOF, which are both excluded. 



The following conformance requirement is referenced to TS 102 613 [1], clause 9.3.1. 



RQ7 



On receiving a corrupted SWP frame, the CLF shall use the error recovery procedure defined for LLC of 
the last correctly received SWP frame. 



5.6.2.2.2 



Test case 1 : interpretation of incorrectly formed frames - SHDLC RSET frames 



5.6.2.2.2.1 Test execution 

The test procedure shall be executed once for each of following parameters, i.e. types of incorrectly formed frames: 

• RSET frame with wrong CRC 16. 

• RSET frame, no SOF. 

• Frame with no payload and no CRC16 (only SOF and EOF), followed by 2 Bytes with value 'A5'. 

5.6.2.2.2.2 Initial conditions 

• The SHDLC Hnk is estabhshed. 

• No further communication is expected. 

5.6.2.2.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


UICC^T 


Send incorrectly formed SHDLC LLC - RSET frame 




2 


T 


No response 


RQ4, 
RQ6, 
RQ7 


3 


UICC^T 


Send RSET 




4 


T^^UICC 


Complete SHDLC link re-establishment 


RQ1, 
RQ5 
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5.6.2.2.3 



Test case 2: interpretation of incorrectly formed frames - SHDLC l-frames 



5.6.2.2.3.1 Test execution 

The test procedure shall be executed once for each of following parameters, i.e. types of incorrectly formed frames: 

• I-Frame with wrong CRC16. 

• I-Frame, no SOP. 

• Frame with no payload and no CRC16 (only SOP and EOF), followed by 2 Bytes with value 'A5'. 

5.6.2.2.3.2 Initial conditions 

• The SHDLC link is established without support for SREJ; no further communication is expected. 

5.6.2.2.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


UICC^T 


Send corrupted frame followed immediately by l-frame(NS0_S+2,x), where 
NSO_S is the sequence number of the last l-frame sent by the UICC 
simulator which was successfully acknowledged by the terminal. 




2 


T-^UICC 


Send REJ(NS0_S+1) 


RQ4, 
RQ5, 
RQ6, 
RQ7 



5.6.2.3 



Bit stuffing 



5.6.2.3.1 Conformance requirements 

Reference: TS 102 613 [1], clause 9.2.3. 



RQ1 



Zero bit stuffing shall be employed by the transmitting entity when sending the payload and the CRC on 
SWP. After five consecutive bits with the logical value 1 , a bit with the logical value is inserted. 



RQ2 



If the last five bits of the CRC contain the logical value 1 , then no bit with the logical value shall be 
added. 



RQ3 



In a received frame the CLP shall recognize stuffed bits and discard them. 



5.6.2.3.2 Test case 1 : behavior of CLF with bit stuffing in frame 

5.6.2.3.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• There are no test case-specific parameters for this test case. 

5.6.2.3.2.2 Initial conditions 

• The SHDLC link is established and idle, i.e. no further communication is expected. 

5.6.2.3.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


T^^UICC 


Run the representative SWP frame exchange procedure 
Exchange data shall be chosen in such a way that all referenced 
requirements can be fully validated 


RQ1, 
RQ2, 
RQ3 
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5.6.2.4 



Error detection 



5.6.2.4.1 Conformance requirements 

Reference: TS 102 613 [1], clause 9.2.1.4. 



RQ1 



The frame transmitted by CLF shall use the 16 bit frame checking sequence as given in 

ISO/IEC 13239 [9] on bits between SOF and EOF, which are both excluded, to compute the CRCs. 



NOTE 1 : There is no explicite test case for RQ1 in the present document (fully covered by other test cases). 
NOTE 2: Further conformance requirements for TS 102 613 [1], clause 9.2.1.4, are listed in clause 5.6.2.2. 



5.6.3 Supported LLC layers and sub clauses 
5.6.3.1 Supported LLC layers 



5.6.3.1.1 Conformance requirements 

Reference: TS 102 613 [1], clause 9.3. 



RQ1 The CLF shall support the SHDLC layer. 



RQ2 



The CLF shall support the ACT layer. 



RQ3 



The LPDU shall be structured according to TS 102 613 [1]. 



NOTE: RQ1 , RQ2 and RQ3 are validated implicitly in other testcases within the present document. 



5.6.3.2 



Interworking of the LLC layers 



5.6.3.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 9.3.1. 



RQ1 



On receiving a corrupted SWP frame, the CLF shall use the error recovery procedure defined for LLC of 
the last correctly received SWP frame. 



RQ2 



After successful activation of the SWP, if the CLF has data to be sent to the UICC that requires the use 
of the CLT LLC, it shall initiate a CLT LLC session. 



RQ3 



After successful activation of the SWP, if the CLF has no data to be sent to the UICC that require the use 
of the CLT LLC, the CLF shall establish the SHDLC link as soon as possible. 



RQ4 



After the UICC and CLF have established the SHDLC link the CLF shall not send ACT LLC frames. 



RQ5 



After the UICC and CLF have opened a CLT session the CLF shall not send ACT LLC frames. 



RQ6 



After the UICC and the CLF have established the SHDLC link the CLF shall ignore received ACT LLC 
frames. 



RQ7 



After the UICC and the CLF have opened a CLT session the CLF shall ignore received ACT LLC frames. 



RQ8 



To enter the SHDLC LLC for the first time after SWP interface activation, the link establishment 
procedure (as described in TS 102 613 [1], clauses 10.7.2 and 10.7.3) shall apply. 



RQ9 



Once the SHDLC link is established, a CLT session shall not invalidate the SHDLC context and the 
endpoint capabilities negotiated during the SHDLC link establishments. 



RO10 



To enter the CLT LLC from ACT LLC or SHDLC LLC, the CLT session shall be opened (as described in 
TS 102 613 [1], clause 11.6). 



R011 



The CLF shall open a CLT session only when all SHDLC l-frames are acknowledged. 



RQ12 



During a CLT session, if SHDLC LLC frames are received by the CLF, then CLF shall consider the CLT 
session as closed. 



NOTE 
NOTE 
NOTE 



NOTE 4: 



NOTE 
NOTE 
NOTE 



Test cases for RQ3 are given in clause 5.7 of the present document. 

Further conformance requirements for TS 102 613 [1], clause 9.3.1, are listed in clause 5.3.2.3. 

RQ4, RQ5 are non-occurrence RQ. There are no test cases for RQ4 and RQ5 in the present 

document. Addition of test cases for RQ4 and RQ5 is FFS. 

The core specification currently doesn't mandate clearly R02, it is currently present for information 

only. 

The addition of test cases for RQ2 and R03 is FFS. 

Test cases for ROB are given in clause 5.7 of the present document. 

Test cases for RQ1 are given in clause 5.8 of the present document. 
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5.6.3.2.2 Test case 1 : ignore ACT LLC frame reception after the SHDLC link establishment 

5.6.3.2.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• There are no test case-specific parameters for this test case. 

5.6.3.2.2.2 Initial conditions 

• The SHDLC hnk is estabhshed. 



5.6.3.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


UICC^T 


Send ACT SYNC frame. 




2 


T 


No response or response not based on ACT LLC. 


RQ6 


3 


UICC^T 


Send l-frame. 




4 


T^ UICC 


Acknowledge l-frame. 


RQ6 



5.6.3.2.3 



Test case 2: ignore ACT LLC frame reception in CLT session 



5.6.3.2.3.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• CLT LLC transporting ISO/IEC 14443-3 [5] type A data, if available, and CLT LLC transporting 
ISO/IEC 18092 [8] data, if available. 

5.6.3.2.3.2 Initial conditions 

• CLT session is established. 



5.6.3.2.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


UICC^T 


Send ACT SYNC frame. 




2 


T 


No response or response not based on ACT LLC. 


RQ7 


3 


PCD^T 


Transmit RF frame with payload of 4 RF bytes (arbitrary chosen) to the 
terminal. 




4 


T^UICC 


Send CLT frame. 


RQ7 



5.6.3.2.4 Test case 3: CLT session during SHDLC communication 

This test case is FFS. 

5.6.3.2.5 Test case 4: closing condition of CLT session whereas SHDLC link has been 
established before CLT session 

5.6.3.2.5.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• CLT LLC transporting ISO/IEC 14443-3 [5] type A data, if available, and CLT LLC transporting 
ISO/IEC 18092 [8] data, if available. 
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5.6.3.2.5.2 Initial conditions 

• The SHDLC link is established before opening of CLT session. 

• CLT session is established. 



5.6.3.2.5.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


UICC ^ T 


Send l-frame. 




2 


T^ UICC 


Acknowledge l-frame. 




3 


UICC->T 


Send CLT frame. 




4 


T 


No response or response not based on CLT session. 


RQ12 



5.6.4 ACT LLC definition and sub clauses 



5.6.4.1 



ACT LLC definition 



5.6.4.1.1 Conformance requirements 

Reference: TS 102 613 [1], clause 9.4. 



RQ1 The CLF shall ignore the FR bit in frames received from the UICC. 



RQ2 



The CLF shall ignore b8 to bS in the ACTJNFORMATION field. 



RQ3 



The CLF shall not use extended SWP bit durations before it has received an ACT_SYNC frame with an 
ACT_INFORMATION field which indicates support of extended SWP bit durations during the initial 
interface activation. 



NOTE 1 : RQ3 is a non-ocurrence requirement. There are no test cases for RQ3 in present document, addition of 

test cases for RQ3 is FFS. 
NOTE 2: The addition of test cases for RQ1 and R02 is FFS. 
NOTE 3: Further conformance requirements for TS 1 02 61 3 [1 ], clause 9.4, are listed in clause 5.3.2.3. 



5.6.4.2 



SYNC_ID verification process 



5.6.4.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 9.4.1. 



RQ1 



The CLF shall support SYNCJD verification. 



RQ2 



The SYNC_ID verification shall always be executed when SWP interface is activated. 



RQ3 



The CLF shall perform the SYNC_ID verification process using the ACT_DATA field of the received 
ACT_SYNC frame as verification data to compare it with identity reference data. 



RQ4 



If the CLF evaluates that verification data and identity reference data values are equal, then the identity 
check is successful. 



RQ5 



If the verification data and identity reference data are not equal, then the identity check failed and the 
CLF shall not open a CLT session. 



NOTE: SYNCJD verification is tested in clause 5.8 of the present document. 



5.6.4.2.2 



Test case 1 : not matching SYNC_ID verification in low power mode 



5.6.4.2.2.1 Test Execution 

The test procedure shall only be executed in voltage class C, low power mode. 
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Initial conditions 



After performing a contactless card application according to "Non ISO/IEC 14443-4 [6] Type A" as described in 
TS 102 622 [4], where a corresponding CLT session was opened, the terminal has deactivated the UICC. The 
verification data of the previously performed SWP interface activation is referenced as SYNC_ID_1. 



5.6.4.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate VCC, SWIO 




2 


T^UICC 


Activate Vcc (contact C1) 




3 


T^ UICC 


Activate SWIO (contact C6) 




4 


UICC^^T 


Perform SWP interface activation, where the UICC sends a SYNC ID 
different to SYNC ID 1 


R01, 
R02 


5 


User ^ T 


Attempting to launch a contactless card application according to "Non 
ISO/IEC 14443-4 [6] Type A" as described in TS 102 622 [4] 




6 


T 


The 2"'^ bullet point of the procedure described in "Non ISO/IEC 14443-4 [6] 
Type A" as described in TS 1 02 622 [4] is not executed 


R01, 
R02, 
R03, 
R05 



5.7 SHDLC LLC definition 

5.7.1 SHDLC overview 

5.7.1.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.1. 



RQ1 



The SHDLC layer in an endpoint shall ensure that data passed up to the next layer has been received 
exactly as transmitted (i.e. error free, without loss and in the correct order). 



RQ2 I If an endpoint receives a corrupted frame, it shall discard the frame. 



NOTE: R01 is out of scope of the present document. 



5.7.1 .2 Test Case 1 : data passed up to the next layer 

5.7.1.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• There are no test case-specific parameters for this test case. 

5.7.1.2.2 Initial conditions 

• SHDLC Hnk is estabHshed. 

• A pipe (PIPE_LOOP_BACK) has been created to the HCI host's loopback gate, and is currently open. 

5.7.1 .2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


UICC ^ T 


Send an EVT POST DATA containing '01 02 03 04' on 
PIPE LOOP BACK. 




2 


T^ UICC 


Send an EVT POST DATA containing '01 02 03 04' on 
PIPE LOOP BACK. 


R01 
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5.7.1 .3 Test Case 2: error management - corrupted l-frame 

5.7.1.3.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• There are no test case-specific parameters for this test case. 

5.7.1.3.2 Initial Conditions 

• SHDLC link is established and idle, i.e. no further communication is expected. 

5.7.1 .3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


UICC->T 


Send a corrupted l-frame (NSO S,x) 




2 


T^ UICC 


The T does not send an acknowledgment 


RQ2 


3 


UICC-»T 


UICC waits 10 ms and sends a correct l-frame (NSO S,x) 




4 


T^UICC 


Acknowledge the receiced l-frame 





5.7.1 .4 Test Case 3: error management - corrupted RR frame 

5.7.1.4.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• There are no test case-specific parameters for this test case. 

5.7.1.4.2 Initial Conditions 

• SHDLC link is established and idle, i.e. no further communication is expected. 

5.7.1 .4.3 Test procedure 



step 


Direction 


Description 


RQ 


1 


UICC^T 


Trigger the T to send an l-frame 




2 


T^ UICC 


Send l(NSO Tx) 


RQ2 


3 


UICC^T 


Send a corrupted RR(NSO T+1) frame 




4 


UICC 


Wait T2 time and don't acknowledge the received frame 




5 


T^UICC 


Send l(NSO T,x) 


RQ2 



5.7.2 Endpoints 



5.7.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.2. 
There are no conformance requirements for the terminal for the referenced clause. 



5.7.3 SHDLC frames types 



5.7.3.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.3. 
There are no conformance requirements for the terminal for the referenced clause. 
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5.7.4 Control Field 

5.7.4.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.4. 
All conformance requirements for the referenced clause are included in clause 5.7.7.3.1 of the present document. 

5.7.4.2 l-Frames coding 

5.7.4.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.4.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.4.3 S-Frames coding 
5.7.4.3.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.4.2. 



RQ1 Optional type of frame shall not be used before capability negotiation is defined during initialization. 



RQ2 



Only one SREJ shall remain outstanding on each link direction at any one time. 



R03 



An endpoint shall not send a S-frame with an information field. 



R04 |An SREJ shall be transmitted for each erroneous frame; each frame is treated as a separate error. 



NOTE 1 : RQ1 , RQ2 and RQ4 for the referenced clause are included in clause 5.7.7.9.1 of the present document. 
NOTE 2: RQ3is a non-occurence RQ and therefore is not tested. 



5.7.4.4 U-Frames coding 

5.7.4.4.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.4.3. 



RQ1 I An endpoint shall only send U-Frames using modifiers specified in TS 102 613 [1] 



NOTE: R01 is not tested, as it is a non-occurrence RQ. 



5.7.5 Changing sliding window size and endpoint capabilities 

5.7.5.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.5. 
All conformance requirements for the referenced clause are included in clause 5.7.7.3.1 of the present document. 

5.7.5.2 RSET frame payload 
5.7.5.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.5.1. 
All conformance requirements for the referenced clause are included in clause 5.7.7.3.1 of the present document. 
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5.7.5.3 UA frame payload 

5.7.5.3.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.5.2. 
All conformance requirements for the referenced clause are included in clause 5.7.7.3.1 of the present document. 

5.7.6 SHDLC context 

5.7.6.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.6. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.6.2 Constants 

5.7.6.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.6.1. 



RQ1 l-frames shall be acknowledged within T1 . 



RQ2 



If the l-frames are not acknowledged, an endpoint shall retransmit these frames not sooner than T2. 



RQ3 



An endpoint shall retry to setup link if the targeted endpoint did not answer with a UA or a RSET frame 
to a RSET frame within T3 (5 ms). 



NOTE 1 
NOTE 2 
NOTES 



RQ1 for the referenced clause is included in clause 5.7.7.5.1 of the present document. 
RQ2 for the referenced clause is included in clause 5.7.7.7.1 of the present document. 
RQ3 for the referenced clause is included in clause 5.7.7.3.1 of the present document. 



5.7.6.3 Variables 

5.7.6.3.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.6.2. 
All conformance requirements for the referenced clause are included in clause 5.7.7.5.1 of the present document. 

5.7.6.4 Initial Reset state 
5.7.6.4.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.6.3. 



R01 



The following initial states shall apply in every endpoint after successful link establishment: 
N(S) = N(R) = DN(R) = 0. 



5.7.6.4.2 Test case 1 : initial state at link reset - reset by the UICC 

5.7.6.4.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 
• There are no test case-specific parameters for this test case. 
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5.7.6.4.2.2 Initial conditions 

• SHDLC link is established and idle, i.e. no further communication is expected. 

5.7.6.4.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


UICC^T 


Send RSET(Ws=2, SREJ=0) 




2 


T^ UICC 


Send UA 




3 


Conditional 


If the T does not immediately send l-frames after SHDLC link establishment, 
trigger the T to send an l-frame. 

If the trigger involves sending l-frames to the terminal, only one l-frame shall 
be sent. 




4 


T^UICC 


Send l-frame(0, NR). 

If the trigger in step 3 involved sending an l-frame to the terminal, NR = 1 , 

else NR = 0. 


RQ1 


5 


UICC^T 


Send RR(1) 




6 


Conditional 


If the T continue to send l-frames, acknowledge them 




7 


UICC^T 


Send l-frame(NS, NR) 




8 


T->UICC 


Acknowledge the previously sent l-frame 


RQ1 



5.7.7 SHDLC sequence of frames 
5.7.7.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.7. 
There are no conformance requirements for the terminal for the referenced clause. 



5.7.7.2 



Nomenclature 



5.7.7.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.7.1. 
There are no conformance requirements for the terminal for the referenced clause. 



£75/ 



Release 9 



63 



ETSI TS 102 694-1 V9.2.0 (2013-04) 



5.7.7.3 



Link establishment with default sliding window size 



5.7.7.3.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.7.2, 10.7.4, 10.4, 10.5, 10.1 and 10.5.2. 



RQ1 


10.7.2 


An endpoint establishing an SHDLC link shall initiate link establishment by sending a RSET frame. 


RQ2 


10.7.2 


If an endpoint supports the sliding window size and SREJ value in the RSET frame, it shall 
acknowledge that frame with a UA frame. 


RQ3 


10.7.2 


An endpoint receiving a RSET frame without window size and/or endpoint capabilities field shall 
interpret the RSET frame as if it contained the default values. 


RQ4 


10.7.2 


Before link establishment, all SHDLC frames except RSET from other endpoint shall be discarded. 


RQ5 


10.7.2 


If the link is re-established, all buffered frames (received out of order or stored in the retransmission 
queue) shall be discarded. 


RQ6 


10.7.2 


If the link is re-established, an endpoint shall inform the upper layer of a link reset. 


RQ7 


10.7.2 


An endpoint shall support a link re-establishment which is initiated by the peer endpoint. 


RQ8 


10.4 


An endpoint's default size of sliding window shall be four frames. 


RQ9 


10.5 


If the initial sliding window size is too large or SREJ support is requested and the receiving endpoint 
can not handle (at least one) of those features, it shall not acknowledge the RSET frame. Instead, the 
receiver shall send a RSET frame with an appropriate sliding window size and/or SREJ frame support 
bit. 


RQ10 


10.5 


An endpoint shall obey to window size reconfiguration and/or SREJ support if the requested window 
size is lower than its default configuration or the peer endpoint does not support SREJ frames. 


RQ11 


10.5.1 


The number provided for the endpoint sliding window size shall be between 2 to 4 inclusive. 


RQ12 


10.5.1 


In case this RSET frame is sent in response to a received RSET frame, the window size value shall 
be equal or lower than the previously provided value. 


RQ13 


10.5.1 


If an RSET frame is received without the second optional byte the default value of SREJ not 
supported should be used. 


RQ14 


10.6.1 


An endpoint shall retry to setup link if the targeted endpoint did not answer with a UA or a RSET 
frame to a RSET frame within T3 (5 ms). 


RQ15 


10.7.4 


Once the link is established, an endpoint shall be able to receive data. 


RQ16 


10.5.2 


The endpoint shall not include a payload in UA frames. 


RQ17 


10.5 


If one or more of the indicated endpoint capabilities are not supported by the receiving endpoint, it 
shall answer with a RSET frame indicating only the supported endpoint capabilities. In this case the 
RSET response may contain the same window size. 


RQ18 


10.5.1 


A RSET frame response shall not indicate the same window size and the same endpoint capabilities 
as the received RSET frame; in such a case a UA frame shall be sent. 


NOTE 1 : Tests for RQ6 are out of scope of the present document. 

NOTE 2: Part of RQ5 related to discarding frame in tine retransmission buffer when the link is re-establish will not be 

tested. 
NOTE 3: RQ4 is not tested as it is not possible to guarantee that an SHDLC frame sent by the UICC simulator will be 

sent before the first RSET frame sent by the terminal. 



5.7.7.3.2 



Test Case 1 : link establishment by the UICC 



5.7.7.3.2.1 Test execution 

The test procedure shall only be executed for RSET values, from the following table, that are supported by the terminal. 



RSETQ 



RSET(2) 



RSET(3) 



RSET(4) 



RSET(2, SREJ^G) 



RSET(2, SREJ^I) 



RSET(3, SREJ^O) 



RSET(3, SREJ^I) 



RSET(4, SREJ^O) 



RSET(4, SREJ^I) 



SREJ should be tested only for the biggest window size supported by the terminal. 
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5.7.7.3.2.2 Initial conditions 

• SHDLC link is established and idle, i.e. no further communication is expected. 

5.7.7.3.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


UICC ^ T 


Send the RSET frame indicated in the test execution clause 




2 


T^ UICC 


Send UA 


R02, 

R03 

R07, 

RQ13, 

R016, R018 


3 


UICC^T 


Send an l-frame 




4 


T^UICC 


Acknowledges the previously sent l-frame 


RQ15 


NOTE 1 : if Terminal sends l-frames between steps 2 and 3, they shall be acknowledged by the UICC. 
NOTE 2: RQ3 is only validated when RSET{) is sent in step 1 . 



5.7.7.3.3 



Test case 2: Link establishment and connection time out 



5.7.7.3.3.1 Test execution 

The test procedure shall be executed once for each of following parameters: 
• There are no test case-specific parameters for this test case. 

5.7.7.3.3.2 Initial conditions 
None of the UICC contacts is activated. 



5.7.7.3.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User -^ T 


Trigger the terminal to activate SWP interface 




2 


UICC^^T 


Perform SWP interface activation 




3 


T->UICC 


Send RSET 


RQ1 


4 


UICC 


Do not send a UA frame 




5 


T^UICC 


Send RSET after at least T3 time after execution of step 3 


RQ14 


6 


UICC^T 


Send an l-frame (0,0) 




7 


T^ UICC 


Send RSET after at least T3 time after execution of step 5 


RQ14 


8 


UICC-»T 


Send UA 




9 


UICC-^T 


Send an l-frame 




10 


T->UICC 


Acknowledge the previously sent l-frame 


R015 
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5.7.7.3.4 



5.7.7.3.4.1 



Test Case 3: requesting unsupported window size and/or SREJ support - link 
establishment by UICC 

Test execution 



Run the test procedure for every row in the table below. If the terminal supports window size 4, the first row (RSET()) 
shall be skipped. 



RSET frame to be sent in step 1 


Valid RSET frames which can be received in step 2 


RSETQ 


RSET(3) 
RSET(2) 

RSET(3, SREJ=0) 
RSET(2, SREJ=0) 


RSET(4, SREJ=1) 


RSETO 
RSET(4) 

RSET(4, SREJ=0) 
RSET(3) 

RSET(3, SREJ=0) 
RSET(3, SREJ=1) 
RSET(2) 

RSET(2, SREJ=0) 
RSET(2, SREJ=1) 



5.7.7.3.4.2 Initial conditions 

• SHDLC hnk is estabUshed. 



5.7.7.3.4.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


UICC^T 


Send the RSET frame indicated in the test execution clause for 
step 1 . 




2 


T^UICC 


Send RSET frame containing values which are supported by the 
terminal and are indicated as valid in the test execution clause for 
step 2. 


RQ3, 

RQ9, 

RQ11, 

RQ12, RQ17 


3 


UICC ^ T 


Respond UA. 




NOTE: RQ3 is only validated when RSET() is sent in step 1 . 



5.7.7.3.5 Test Case 4: forcing lower window size and SREJ not used - link establishment 

by the T 

5.7.7.3.5.1 Test execution 

The test procedure shall be executed once for each of following parameters: 
• There are no test case-specific parameters for this test case. 

5.7.7.3.5.2 Initial conditions 
None of the UICC contacts is activated. 
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5.7.7.3.5.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the terminal to activate SWP interface 




2 


UICC^^T 


Perform SWP interface activation 




3 


T^UICC 


Send RSET frame 

If the terminal sends an RSET(WS=2, SREJ=0) frame, then do not 

continue this test. In this case, it shall not be considered failed 




4 


UICC^T 


Send RSET(WS=2, SREJ=0) frame 




5 


T^ UICC 


Send UA 


RQ2, 
RQ10, RQ18 



5.7.7.3.6 



Test case 5: discard buffered frames on link re-establishment 



5.7.7.3.6.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• There are no test case-specific parameters for this test case. 

5.7.7.3.6.2 Initial conditions 

• The SHDLC link is established with SREJ support 

• SHDLC link is idle, i.e. no further communication expected 



5.7.7.3.6.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


UICC^T 


Send l-frame(NSO S,x) 




2 


T^ UICC 


Acknowledges l-frame(NSO S,x) 




3 


UICC-»T 


Send l-frame(NSO S+2,x) 




4 


T^ UICC 


SendSREJ(NSO S+1) 




5 


UICC ^^ T 


Re-establish SHDLC link 




6 


UICC^ ^T 


UICC sends l-frame(0,NR) to l-frame(NS0_S+1,NR) 
T acknowledges these l-frames 


RQ5 



5.7.7.4 



Link establishment with custom sliding window size 



5.7.7.4.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.7.3. 
There are no conformance requirements for the terminal for the referenced clause. 
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Data flow 



5.7.7.5.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.7.4, 10.6.1, 10.6.2 and 9.2.2. 



RQ1 


10.7.4 


An endpoint shall acknowledge frame reception regularly. 


RQ2 


10.7.4 


The acknowledgement timeout shall not be too long. 


RQ3 


10.7.4 


If the number of unacknowledged l-frames on the link equals the negotiated window size, then the 
endpoint shall not transmit any further l-frames until reception of an acknowledgement. 


RQ4 


10.6.1 


l-frames shall be acknowledged within T1 . 


RQ5 


10.6.2 


An endpoint shall increment its value of the N(S) field after emission of an l-Frame. 


RQ6 


10.6.2, 
10.8.2 


N(R) shall be set as described in TS 1 02 61 3 [1 ]. 


RQ7 


10.6.2 


During full duplex data transmission or by emission of a S type frame, all received frames with a 
sequence number lower than N(R) are acknowledged. 


RQ8 


9.2.2 


Between frames, idle bits (logical value 0) are sent. There is at least one idle bit between frames. 


RQ9 


9.2.2 


The CLF shall correctly interpret error free frames sent by UICC with at least one idle bit between the 
frames. 


NOTE 1 : RQ2 is covered by RQ1 and therefore will not be mentioned explicitly in test procedures. 

NOTE 2: RQ4 (i.e. conformance to T1) is not tested, as the CLF cannot be forced to delay the acknowledgement 

beyond T1 . 
NOTE 3: RQ3 is tested in clause 5.7.7.7. 



5.7.7.5.2 



Test case 1 : l-frame transmission 



5.7.7.5.2.1 Test execution 
Run this test procedure for: 

• Every supported window size: 

Every I-frame is acknowledged individually by the ES. 

5.7.7.5.2.2 Initial conditions 

• SHDLC link is established with the window size indicated in the test execution clause. 

• SHDLC link is idle, i.e. no further communication is expected. 

5.7.7.5.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the T to send 9 l-frames 




2 


T^ UICC 
UICC^T 


T send l-Frames as indicated in step 1 

UICC acknowledges these frames using the acknowledgement mechanism 

indicated in the test execution clause, using RR frames. 


RQ5, 
RQ6, 
RQ7, 
RQ8 



5.7.7.5.3 



Test case 2: l-frame reception - single l-Frame reception 



5.7.7.5.3.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• There are no test case-specific parameters for this test case. 

5.7.7.5.3.2 Initial conditions 

• SHDLC link is established and idle, i.e. no further communication is expected. 
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5.7.7.5.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


UICC^T 


Send 10 l-frames, waiting the acknowledgement of the previously sent 
l-frame before sending the next l-frame 




2 


T^ UICC 


T acknowledges these l-frames 


RQ1, 
RQ6 


3 


conditional 


If retransmission occurs, perform steps 4 and 5 




4 


UICC-^T 


Send 10 l-frames, waiting the acknowledgement of the previously sent 
l-frame before sending the next l-frame 




5 


T^UICC 


T acknowledges these l-frames, without requiring retransmission by the 
UICC 


RQ1, 
RQ6 



5.7.7.5.4 Test case 3: l-frame reception - multiple l-Frame reception 

5.7.7.5.4.1 Test execution 

• Run this test procedure for every supported window size. 

5.7.7.5.4.2 Initial conditions 

• SHDLC link is established with the window size indicated in the test execution clause. 

• SHDLC link is idle, i.e. no further communication is expected. 

5.7.7.5.4.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


UICC^T 


Send 10 l-frames. 

The UICC shall send each l-frame within T1 , without waiting for the 
acknowledgement of the previously sent l-frame, while still complying to the 
negotiated window size. There shall be at least two occurrences of 
consecutive l-frames transmitted with a single idle bit between the frames. 




2 


T^UICC 


T acknowledges these frames. 


RQ1, 
RQ6, 
RQ9 


3 


conditional 


If retransmission occurs, perform steps 4 and 5. 




4 


UICC^T 


Send 10 l-frames. 

The UICC shall send each l-frame within T1 , without waiting for the 
acknowledgement of the previously sent l-frame, while still complying to the 
negotiated window size. There shall be at least two occurrences of 
consecutive l-frames transmitted with a single idle bit between the frames. 




5 


T^ UICC 


T acknowledges these frames, without requiring retransmission by the 
UICC. 


RQ1, 
RQ6, 
RQ9 



5.7.7.6 



Reject (go N back) 



5.7.7.6.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.7.5 and 10.1. 



RQ1 


10.7.5 


If an endpoint detects missing l-frame sequence numbers and if SREJ is not supported or if several 
frames got lost, the endpoint shall send a REJ frame as soon as possible. 


RQ2 


10.7.5 


When an endpoint receives a REJ frame with a sequence number which identifies an 
unacknowledged l-frame previously sent within the sliding window size it shall restart the stream at 
the first missing frame. 


RQ3 


10.7.5 


After sending REJ, an endpoint shall accept the peer endpoint restarting the stream at the first 
missing frame. 
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5.7.7.6.2 Test case 1 : REJ transmission - multiple l-frames received 

5.7.7.6.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• There are no test case-specific parameters for this test case. 

5.7.7.6.2.2 Initial conditions 

• SHDLC link is estabUshed with WS=3 and without SREJ support. 

• SHDLC link is idle, i.e. no further communication is expected. 

5.7.7.6.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


UICC-^T 


Send l-frame(NSO S,x) 




2 


T-^ UICC 


Acknowledge l-frame(NSO S,x) 




3 


UICC^T 


Send l-frame(NSO S+2,x) followed immediately by l-frame(NSO S+3,x) 




4 


T^UICC 


Send REJ(NS0_S+1) 

The DUT is allowed to send additional REJ{NS0_S+1), in response to any 

additional l-frame{NSO S+x,x) 


RQ1 


5 


UICC^-^T 


UICC send 10 l-frames starting at l-frame{NS0_S+1,x) 
T acknowledge l-frames 


RQ3 



5.7.7.6.3 



Test case 2: REJ reception 



5.7.7.6.3.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• There are no test case-specific parameters for this test case. 

5.7.7.6.3.2 Initial conditions 

• SHDLC link is established without SREJ support. 

• SHDLC link is idle, i.e. no further communication is expected. 
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Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the T to send l-frames 




2 


T^UICC 


Send l-frame(NSO T, y) 




3 


UICC 


Do not acknowledge l-frame(NSO T,y) 




4 


T^UICC 


If the Terminal transmit a frame within T1 , it shall be (NS0_T+1 ,y). Then 
continue to step 5 (depending on the WS, additional l-frames may be sent) 

If the Terminal transmit a frame within T1 , it shall be (NS0_T+1 ,y). if there is 
no acknowledgement within T1 , Then continue to step 5 (depending on the 
WS, additional l-frames may be sent) 

If no further transmission occurs within T1 , the Terminal shall retransmit 
(NSO_T,y). Then stop the test procedure, as it is not possible for the UICC to 
send a valid REJ. This is not a failure of the Terminal 




5 


UICC-^T 


Send REJ(NSO_T) 

The UICC is required to send additional REJ(NSO_T), in response to any 

additional l-frame(NSO T-i-x,y) 




6 


T-^ UICC 


Send l-frame(NSO T,y) 


RQ2 


7 


UICC^T 


acknowledge l-frame(NSO T,y) 




8 


T^ UICC 


Send l-frame(NSO T-i-1 ,y) 


RQ2 


9 


UICC^T 


acknowledge l-frame(NSO T-i-1 ,y) 





5.7.7.7 



Last Frame Loss 



5.7.7.7.1 Conformance requirements 

Reference: TS 102 613 [1], clauses 10.7.4, 10.7.6 and 10.6.1. 



RQ1 


10.7.6 


Each frame shall have a guarding/transmit timeout in order to retransmit frames if the destination does 
not notice a loss. 


RQ2 


10.6.1 


If the l-frames are not acknowledged, an endpoint shall retransmit these frames not sooner than T2. 


RQ3 


10.7.4 


If the number of unacknowledged l-frames on the link equals the negotiated window size, then the 
endpoint shall not transmit any further l-frames until reception of an acknowledgement. 



5.7.7.7.2 



Test Case 1 : retransmission of multiple frames 



5.7.7.7.2.1 Test execution 
Run this test procedure for: 

• Every supported window size: 

I-frames are acknowledged by the ES just before Tl expires and using the maximum allowed value for 
NR. 

5.7.7.7.2.2 Initial conditions 

• SHDLC link is established without SREJ support. 

• SHDLC link is idle, i.e. no further communication is expected. 
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Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the T to send 9 l-frames 




2 


T-> UICC 


T send l-frames as indicated in step 1, respecting the negotiated window 
size 


RQ3 


3 


UICC 


UICC does not acknowledge the l-frame(s) within T1 




4 


T^ UICC 


After T2 (calculated from the first non acknowledge frame), the terminal 
retransmits the l-frame(s) respecting the window size 


RQ1, 
RQ2, 
RQ3 


5 


UICC -^ T 


Acknoledges the received l-frame(s) within T1 





5.7.7.8 



Receive and not ready 



5.7.7.8.1 Conformance requirements 

Reference: TS 102 613 [1], clauses 10.7.7 and 10.1. 



RQ1 


10.7.7 


When an endpoint transmits a RNR and is now ready to receive an l-Frame, it shall send a RR frame 
every 5 ms to 20 ms until it receives a new l-frame. 


RQ2 


10.7.7 


If an endpoint receives a RR in a context described in RQ1 and has no data to send, it shall send an 
l-Frame with empty information field to signal the proper reception of the RR frame. 


RQ3 


10.7.7 


If an endpoint receives RNR frame then it shall suspend transmission of l-frames within the negotiated 
WS. 


RQ4 


10.7.7 


If an endpoint receives a RR in a context described in RQ1 and still has data to send, it shall resume 
the l-Frame(s) transmission. 


NOTE: RQ1 will not be tested as it is not possible to trigger the T to transmit a RNR. 



5.7.7.8.2 Test case 1 : RNR reception 

5.7.7.8.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• There are no test case-specific parameters for this test case. 

5.7.7.8.2.2 Initial conditions 

• SHDLC link is established and idle, i.e. no further communication is expected. 

5.7.7.8.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


User -» T 


Trigger the T to send 9 l-frames 




2 


T^ UICC 


Start sending l-frames 




3 


UICC^T 


Acknowledge the first received l-frame(NSa T,x) with RNR(NSa T-i-1) 




4 


UICC 
T^UICC 


Wait 100 ms 

The terminal may send further l-frames within the negotiated WS; in this 

case the UICC should not acknowledge these l-frames. 


RQ3 


5 


UICC^T 


Send RR, every 5 ms to 20 ms until a new l-Frame is received where N(R) = 
NSa T-hI 




6 


T^ UICC 
UICC ^ T 


T sends remaining l-frames, where N(S) of the first l-frame = NSa_T-i-1 
UICC acknowledges remaining l-frames 


RQ3 
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5.7.7.8.3 Test case 2: Empty l-frame transmission 

5.7.7.8.3.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• There are no test case-specific parameters for this test case. 

5.7.7.8.3.2 Initial conditions 

• SHDLC link is established and idle, i.e. no further communication is expected. 

5.7.7.8.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


User -^ T 


Trigger the T to send 1 l-frame 




2 


T->UICC 


Send l-frame(NSa T,x) 




3 


UICC^T 


Acknowledge l-frames(NSa T,x) with RNR(NSa T+1) 




4 


UICC^T 


Send RR(NSa T+1) 




5 


T^UICC 


Send empty l-frame(NSa T+1,x) 


RQ2 


6 


UICC -^ T 


Send acknowledgement of frame(NSa_T+1 ) 





5.7.7.9 



Selective reject 



5.7.7.9.1 Conformance requirements 

Reference: TS 102 613 [1], clauses 10.7.8, 10.8.2, 10.1 and 10.4.2. 



RQ1 


10.8.2 


If an l-frame (x,y) Is received by an endpoint and support for Selective Reject S frames was 
negotiated for the link and X Is exactly one higher than N(R), a SREJn{r) shall be sent Instead of the 
REJn(r). The received l-frame shall be buffered. 


RQ2 


10.8.2 


Once the retransmitted l-frame with X = N(R) Is received In the context of R03, the buffered l-frame 
shall also be processed. 


RQ3 


10.7.8 


If an endpoint receives a SREJ frame and supports for SREJ was agreed at link establishment, It shall 
retransmit the corresponding l-Frame. 


RQ4 


10.4.2 


Only one SREJ shall remain outstanding on each link direction at any one time. 


RQ5 


10.4.2 


An SREJ shall be transmitted for each erroneous frame; each frame is treated as a separate error. 


RQ6 


10.4.2 


Optional type of frame shall not be used before capability negotiation Is defined during initialization. 


NOTE: RQ6 Is a non-occurrence RQ. There are no test cases for RQ6. 



5.7.7.9.2 



Test case 1 : SREJ transmission 



5.7.7.9.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• There are no test case-specific parameters for this test case. 

5.7.7.9.2.2 Initial conditions 

• The SHDLC Unk is established with SREJ support. 

• SHDLC link is idle, i.e. no further communication is expected. 
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Test procedure 



Step 


Direction 


Description 


RQ 


1 


UICC^T 


Send l-frame(NSO S,x) 




2 


T->UICC 


Acknowledge l-frame(NSO S,x) 




3 


UICC^T 


Send l-frame(NSO S+2,x) 




4 


T^UICC 


SendSREJ(NSO S+1) 


RQ1 


5 


UICC^T 


Sends l-frame(NSO S+1,x) 




6 


T^ UICC 


Acknowledges l-frame(NSO S+1,x) and l-frame(NSO S+2,x) 




7 


UICC^T 


Send l-frame(NSO S+3, x) 




8 


T^ UICC 


Acknowledges l-frame(NS0_S+3,x) 


RQ2 



5.7.7.9.3 
FFS 



Test case 2: SREJ transmission - multiple l-frames received 



5.7.7.9.4 Test case 3: SREJ reception 

5.7.7.9.4.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• There are no test case-specific parameters for this test case. 

5.7.7.9.4.2 Initial conditions 

• SHDLC link is estabUshed with SREJ support. 

• SHDLC link is idle, i.e. no further communication is expected. 

5.7.7.9.4.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


User ^ T 


Trigger the T to send 9 l-frames with as small a delay between subsequent 
l-frames as possible 




2 


T^ UICC 


Send l-frame(NSO T,x) 




3 


UICC-^T 


Do not acknowledge the received l-frame 




4 


T^ UICC 


If the T retransmits l-frame(NSO_T,x), then stop the test procedure, as it is 
not possible for the UICC to send a valid REJ. This is not a failure of the T 
If the T transmits l-frame(NSO T+1 ,x), then continue the test procedure 




5 


UICC-»T 


Send SREJ(NSO T) 




6 


T^ UICC 


Retransmit only the rejected l-Frame and continue sending remaining 

l-frames 

UICC acknowledges remaining l-frames 


RQ3 



5.7.7.9.5 



Void 



5.7.8 Implementation 



5.7.8.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.8. 
There are no conformance requirements for the terminal for the referenced clause. 
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5.7.8.2 Information Frame emission 
5.7.8.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.8.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.8.3 Information Frame reception 
5.7.8.3.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.8.2. 
All conformance requirements for the referenced clause are included in clause 5.7.7.9.1 of the present document. 

5.7.8.4 Reception Ready Frame reception 
5.7.8.4.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.8.3. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.8.5 Reject Frame reception 
5.7.8.5.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.8.4. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.8.6 Selective Reject Frame reception 
5.7.8.6.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.8.5. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.8.7 Acl^nowledge timeout 
5.7.8.7.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.8.6. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.8.8 Guarding/transmit timeout 
5.7.8.8.1 Conformance requirements 

Reference: TS 102 613 [1], clause 10.8.7. 
There are no conformance requirements for the terminal for the referenced clause. 
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5.8 CLT LLC definition 

5.8.1 System Assumptions 

Reference: TS 102 613 [1], clause 11.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.8.2 Overview 

5.8.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 11.2. 
There are no conformance requirements for the terminal for the referenced clause. 

5.8.3 Supported RF protocols 
5.8.3.1 Conformance requirements 

Reference: TS 102 613 [1], clause 11.2a. 



RQ1 



For IS0/IEC1 4443-3 [5] Type A, initialization (anti-collision and selection) of the RF protocol is performed 
by the CLF without UICC involvement. 



RQ2 



The UICC provides initialization data to the CLF, which performs RF protocol initialization for 
ISO/IEC 18092 [8] 212 kbps/424 kbps passive mode based card emulation protocol. 



NOTE 1 : Development of test cases for RQ2 is FFS. 
NOTE 2: Test case for RQ1 is in clause 5.8.5.2. 



5.8.4 CLT Frame Format 
5.8.4.1 Conformance requirements 

Reference: TS 102 613 [1], clause 11.3. 
Conformance requirements for this clause are given in clause 5.9.2.1.1. 
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5.8.5 CLT Command Set 
5.8.5.1 Conformance requirements 

Reference: TS 102 613 [1], clause 11.4. 



RQ1 


The CLF shall interpret received data in the DATA FIELD as Type A aligned data structure if bit 5 in 
CLT CMD field is 0. 


RQ2 


The CLF shall interpret received data in the DATA FIELD as byte aligned data structure if bit 5 in 
CLT CMD field is 1. 


RQ3 


Bits 1 through 4 of the CLT CIVID field shall contain the ADMIN FIELD. 


RQ4 


The CLF shall indicate a CLT frame representing "no administrative command" by setting the 
ADMIN FIELD in the CLT frame to 0000. 


RQ5 


The CLF shall indicate a CLT frame representing the administrative CL PROTO INF(A) command by 
setting the ADMIN FIELD in the CLT frame to 1 000. 


RQ6 


The CLF shall indicate a CLT frame representing the administrative CL PROTO INF(F) command by 
setting the ADMIN FIELD in the CLT frame to 1 001 . 


RQ7 


The CLF shall not send a CLT frame containing ADMIN FIELD with RFU values. 


RQ8 


The CLF shall interpret a CLT frame containing an ADMIN_FIELD with the value 0000 as "no 
administrative command". 


RQ9 


The CLF shall interpret a CLT frame containing an ADMIN_FIELD with the value 0001 as an 
administrative command CL_GOTO_INIT to enter the initial state of the RF protocol initialization 
sequence. 


RQ10 


The CLF shall interpret a CLT frame containing an ADMIN_FIELD with the value 0010 as an 
administrative command CL_GOTO_HALT to enter the "HALT" state of the RF protocol initialization 
sequence. 


NOTE 1 : RQ7 is a non-occurrence requirement and tlierefore is not tested. 
NOTE 2: Development of test cases for RQ1 , RQ2, RQ6, RQ9 and RQ1 is FFS. 



5.8.5.2 Test case 1 : IS0/IEC1 4443-3 Type A, no administrative command 

Execution of this test case might require the support of an upper layer (e.g. HCI as per TS 102 622 [4]). This 
information shall be provided by the DUT manufacturer. 

The test equipment shall provide a PCD capable to perform ISO/lEC 14443-3 [5] type A RF communication, with RF 
frame reception length of up to 32 bytes. 

5.8.5.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• There are no test case specific parameters for this test case. 

5.8.5.2.2 Initial conditions 

• Initialization of 1SO/1EC14443-3 [5] Type A protocol was successfully performed; a CLT session 
(ISO/lEC 14443-3 [5] Type A) is opened, and no further CLT frame exchange is expected. 



5.8.5.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


PCD^T 


Transmit RF frame with payload of 4 RF bytes (arbitrary chosen) to the 
terminal 




2 


T^ UICC 


Send a "no administrative command" CLT frame in Type A aligned format 
containing the given RF data 


RQ3, 
RQ4 


3 


UICC^T 


Respond a "no administrative command" CLT frame in Type A aligned 
format containing 18 bytes (arbitrary chosen) of RF data (encoded in CLT 
PAYLOAD) 




4 


T-> PCD 


Transmit RF frame to the terminal containing the resulting RF data 


RQ8 
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5.8.6 CLT Frame Interpretation 



5.8.6.1 



CLT frames with Type A aligned DATA_FIELD 



5.8.6.1.1 Conformance requirements 

Reference: TS 102 613 [1], clause 11.5.1. 



RQ1 



When the CLF receives a CLT frame with Type A aligned DATAFIELD, the bit count shall be retrieved 
implicitly from the length of the CLT PAYLOAD, where the interpretation rule is defined as table 1 1 .3 in 
TS102 613[1]. 



RQ2 



When the CLF sends a CLT frame with Type A aligned DATA_FIELD, the size of the CLT PAYLOAD 
shall be determined according to table 1 1 .2 in TS 1 02 61 3 [1 ] and the number of RF bits to be sent. 
When the CLF receives a CLT frame with Type A aligned DATA_FIELD it shall interpret it as an 
instruction to send N full bytes plus N parity bits over the RF where N is determined from the size of the 
DATA_FIELD according to table 11 .3, for 1 < N < 25. 



RQ3 



RQ4 



When the CLF receives a CLT frame with a Type A aligned DATA_FIELD of a size of one byte it shall 
interpret it as an instruction to send the least significant 4 bits over the RF. 



NOTE: 



RQIto RQ4 are tested in clause 5.9.2.1. 



5.8.6.2 



Handling of DATA_FIELD by the CLF 



5.8.6.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 11.5.2. 



RQ1 



For ISO/IEC 14443-3 [5] Type A, after the CLF has received an RF frame, a CLT frame with all RF data 
in the DATAFIELD shall be composed and sent to the UICC except for the first frame after RF protocol 
initialization. 



RQ2 



For ISO/IEC 14443-3 [5] Type A, after reception of a CLT frame from the UICC, the CLF shall transmit 
the received data via RF if the CLT frame included a DATAFIELD, if no DATAFIELD was present then 
no data shall be transmitted via RF. 



NOTE 1 
NOTE 2 
NOTE 3 



The 2"d part of RQ1 is covered in clause 5.8.6.3.1 . 
RQ1 is tested in clause 5.9.2.1 .2. 
RQ2 is tested in clause 5.9.2.2.2. 
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5.8.6.3 Handling of ADMIN_FIELD 

5.8.6.3.1 CL_PROTO_INF(A) 



5.8.6.3.1.1 Conformance requirements 

Reference: TS 102 613 [1], clause 11.5.3.1 and 11.2a. 



RQ1 



CL_PROTO_INF(A) shall be sent by the CLF to the UICC after every successful ISO/IEC 14443-3 [5] 
Type A RF protocol initialization. 



After the CLF has sent the SAK as per ISO/IEC 14443-3 [5], on reception of the 1^' RF frame, if the error 
detection code is correct and the RF frame is a Type A standard frame as per ISO/IEC 14443-3 [5] with 
CRC_A appended, and the first byte is not 'EO', '50', '93', '95' or '97', the CLF shall compose a CLT frame 
with ADMIN_FIELD set to CL_PROTO_INF(A) and shall attach the received RF data as DATA_FIELD. 
The RF-type specific error detection code shall not be included and the DATA_FIELD shall be coded in 
"byte-aligned" manner. 



RQ2 



RQ3 



After the CLF has sent the SAK as per ISO/IEC 14443-3 [5], on reception of the f ' RF frame, if the first 
byte is equal to 'EO' (command "RATS" as per ISO/IEC 14443-4 [6]), then the CLF shall continue 
ISO/IEC 14443-4 [6] processing using a higher level protocol out of scope of the present document, no 
CLT frame shall be sent to the UICC. 



RQ4 



After the CLF has sent the SAK as per ISO/IEC 14443-3 [5], on reception of the r' RF frame, if the 
length of the RF data exceeds the maximum size of the DATA_FIELD, no CLT frame shall be sent to the 
UICC. 



R05 



For ISO/IEC 14443-3 [5] Type A, initialization (anti-collision and selection) of the RF protocol is 
performed by the CLF without UICC involvement. 



R06 



During ISO/IEC 14443-3 [5] Type A RF protocol initialization, the CLF shall not send CLT frames. 



NOTE 
NOTE 
NOTE 



Development of test cases for R04 is FFS. 

Test cases for R03 are out of scope of the present document. 

R06 is FFS. 



5.8.6.3.1.2 



Test case 1 : opening a CLT session with CL_PROTO_INF(A) 



Execution of this test case might require the support of an upper layer (e.g. HCI as per TS 102 622 [4]). This 
information shall be provided by the DUT manufacturer. 

The test equipment shall provide a PCD capable to perform ISO/IEC 14443-3 [5] Type A RF communication, with RF 
frame reception length of at least 32 bytes. 

5.8.6.3.1.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• There are no test case specific parameters for this test case. 

5.8.6.3.1.2.2 Initial conditions 

• The SWP interface is idle (in any state), i.e. no further communication is expected. 

• The RF field is not on. 



£75/ 



Release 9 



79 



ETSI TS 102 694-1 V9.2.0 (2013-04) 



5.8.6.3.1.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


PCD-»T 


Turn on RF field 




2 


T^UICC 


Terminal may communicate with UICC as required; for example, activate the 
SWP interface if necessary, and send EVT FIELD ON as specified in 
TS 1 02 622 [4] 




3 


PCD ^^ T 


Perform initialization of the RF IS0/IEC1 4443-3 [5] Type A protocol (with 
anti-collision and selection) 


R05 


4 


PCD^T 


Transmit RF frame with payload of 4 RF bytes to the terminal, where the 
1^' byte is set to '30', the 2"'^ byte to '00', and the bytes 3 and 4 represent the 
correct CRC as per IS0/IEC1 4443-3 [5] Type A 


R01 


5 


T-»UICC 


Send CLT frame with administrative command CL_PROTO_INF(A) in byte 
aligned format containing the 1^' and 2"'^ byte of the given RF data 


R02 


6 


UICC^T 


Respond "no administrative command" CLT frame in Type A aligned format 
containing 18 (arbitrary chosen) RF bytes (encoded in CLT PAYLOAD) 




7 


T^ PCD 


Transmit RF frame to the terminal containing the resulting RF data 




8 


PCD^T 


Send REQA to the terminal 




9 


T^UICC 


Forward the RF data to the UICC by means of a CLT frame with 
ADIVIIN FIELD set to 0000 and having a DATA FIELD length of 1 byte 




10 


UICC^T 


Respond CLT frame with the ADMIN_FIELD CL_GOTO_INIT and no 
DATA FIELD present. 




11 


T 


Send no RF frame to the PCD 




12 


PCD ^^ T 


Perform initialization of the RF IS0/IEC1 4443-3 [5] Type A protocol (with 
anti-collision and selection) (see note) 




13 


PCD^T 


Transmit RF frame with payload of 4 RF bytes to the terminal, where the 
1^' byte is set to '60', the 2"'^ byte to '04', and the bytes 3 and 4 represent the 
correct CRC as per IS0/IEC1 4443-3 [5] Type A 




14 


T^UICC 


Send CLT frame with administrative command CL_PROTO_INF(A) in byte 
aligned format containing the 1^' and 2"'^ byte of the given RF data 


R01 


NOTE: The PCD starts with REQA without cutting off the RF field. 



5.8.6.3.2 



CL_PROTO_INF(F) 



5.8.6.3.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 11.5.3.2. 



R01 



A CLT frame with the ADMiN_FIELD CL_PROTO_INF(F) shall be sent by the CLF to the UICC after 
every reception of an anticollision command ("POLLING REQUEST" command) from RF if the CLF is 
configured to do so. 



R02 



When the CLF has received the initialization command as defined in ISO/lEC 18092 [8] for 
212 kbps/424 kbps passive mode ("POLLING REQUEST", command code '00'), it shall forward the 
received RF data (including the LEN and RF CRC field) to the UICC encapsulated as byte aligned 
DATA_FIELD in a CLT frame with the ADMIN_FIELD CL_PROTO_INF(F) 



RQ3 



On reception of a CLT frame with ADIVIIN_FIELD (OOOO)b, the CLF shall interpret the DATA_FIELD as 
initialization response ("POLLING RESPONSE", Command Code '01', including the LEN and RF CRC 
field), and send it out on RF side according to the initialization procedure as defined in ISO/lEC 18092 [8] 
for 212 kbps/424 kbps passive mode 



R04 



If the CLF has received a CLT frame without a DATA_FIELD with respect to ISO/lEC 18092 [8] and 
21 2 kbps/424 kbps passive mode, the CLF shall not transmit any data via RF 



NOTE: Development of test cases for CL_PROTO_INF(F) is FFS. 
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5.8.6.3.3 



CL GOTO INIT and CL GOTO HALT 



5.8.6.3.3.1 Conformance requirements 

Reference: TS 102 613 [1], clause 11.5.3.3. 



RQ1 



If the CLF was selected from IDLE state and the CLF receives a ADMIN_FIELD containing 
CL GOTO INIT the CLF shall enter the IDLE state. 



RQ2 



If the CLF was selected from HALT state and the CLF receives a ADMINFIELD containing 
CL GOTO INIT the CLF shall enter the HALT state. 



RQ3 



If the CLF receives a ADMIN_FIELD containing CL_GOTO_HALT the CLF shall enter the HALT state. 



RQ4 



After the transition to ISO/IEC 14443-3 [5] "IDLE" or "HALT" state, the CLF shall process 

ISO/IEC 14443-3 [5] Type A RF protocol initialization, and proceed as described in clause 1 1 .5.3.1 in 

TS102 613[1]. 



NOTE: 



These ROs are tested in clause 5.9.2.2.2. 



5.8.7 CLT Protocol Rules 



5.8.7.1 



Rules for the CLF 



5.8.7.1.1 Conformance requirements 

Reference: TS 102 613 [1], clause 11.6. 



RQ1 



In order to open a new CLT session, the CLF shall send a CLT frame with ADMIN_FIELD set to 
CL_PROTO_INF(A) or CL_PROTO_INF(F) to the UICC and shall close also any former CLT session. 



RQ2 



After having sent a CLT frame with ADMIN_FIELD set to CL_PROTO_INF(A), subsequently sent CLT 
frames within the CLT session shall be coded in Type A aligned manner. 



RQ3 



During a CLT session, on reception of a corrupted SWP frame or a CLT frame which contains an 
ADMIN_FIELD set to a value which is reserved for future use, the CLF shall maintain the CLT LLC layer. 



NOTE: Development of test cases for RQ1 to R03 is FFS. 



5.8.7.2 Rules for the UICC 

Reference: TS 102 613 [1], clause 11.6.2. 
There are no conformance requirements for the terminal for the referenced clause. 



5.9 Timing and performance 
5.9.1 SHDLC Data transmission mode 



5.9.1.1 



CLF processing delay when receiving data over an RF-link 



5.9.1 .1 .1 Conformance requirements 

Reference: TS 102 613 [1], clause 12.1.1. 



RQ1 The CLF shall be able to send one or multiple l-frames over the SWP link to the UICC. 



RQ2 



The CLF shall respect TciF.shdicReceive as specified in TS 102 613 [1]. 



RQ3 



The CLF shall start the transmission of the RF acknowledgement, where required by the RF protocol, 
before the last bit of data related to it has been sent over SWP. 



NOTE: RQ1 to ROS are tested in clause 5.9.1 .2.2. 
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5.9.1.2 



CLF processing delay when sending data over an RF-link 



5.9.1.2.1 Conformance requirements 

Reference: TS 102 613 [1], clause 12.1.2. 



RQ1 



When receiving data from the UICC in one or multiple l-frames; the CLF shall remove the frame 
fragmentation. 



RQ2 



The CLF shall transmit the data conveyed by those l-frames over RF, fragmenting where necessary. 



RQ3 [The CLF shall respect TciF.shdici 



t as specified in TS 102 613 [1]. 



NOTE: In the current version of the specification RQ1 to RQ3 are only tested for non chained RF frames. 



Reference: TS 102 613 [1], clause 12.1.1. 



RQ4 The CLF shall be able to send one or multiple l-frames over the SWP link to the UICC. 



RQ5 



The CLF shall respect TciF.shdicReceive as specified in TS 102 613 [1]. 



RQ6 



The CLF shall start the transmission of the RF acknowledgement, where required by the RF protocol, 
before the last bit of data related to it has been sent over SWP. 



NOTE: In the current version of the specification RQ4 to RQ6 are only tested for non chained RF frames. 



NOTE: TcLF.shdicTransmit & TcLF.shdic.Receive ^6 defined in clauscs 12.1.1 and 12.1.2 of TS 102 613 [1]. These clauses 
define the conditions for which the formulas are valid and the test tool should attempt to ensure that these 
conditions are met. If not, the timings added by the test tool have to be subtracted from the measured 
timings to correctly assess the terminal compliance. 



5.9.1.2.2 



5.9.1.2.2.1 



Test case 1 : Transceiving non-chained data over RF in Card Emulation 



Test execution 



Run this test procedure for: 

• Each of the supported card emulation types (A and B). 

• Each of the scenario described below. 



Scenario number 


Number of Bytes transferred over RF 


1 


INT(V FRAME SIZE CE74) 


2 


INT(V FRAME SIZE CE73) 


3 


INT(V FRAME SIZE CE72) 


4 


INT(V FRAME SIZE CE*) 


NOTE 1 : V_FRAME_SIZE_CE equals V_FRAME_SIZE_CEA for type A and V_FRAME_SIZE_CEB for type B. 
NOTE 2: INT{x) refers here to the integer value of Y. 



5.9.1.2.2.2 Initial conditions 

• SHDLC link is established with the window size indicated in the test execution clause. 

• SHDLC link is idle, i.e. no further communication is expected. 
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5.9.1.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


PCD^T 


Send 1 RF frame (l-Block), with length as defined in the execution clause 




2 


T^UICC 
T^ PCD 


Forward the data payload extracted from the l-Block received on RF 
Acknowledge the received RF frame 


RQ4, 
RQ5,RQ6 


3 


UICC-^T 


Send l-Frame(s), transporting the RF data to be sent to the PCD, as defined 
in the execution clause 




4 


T^ PCD 


Forward the l-Block(s) built from the payload of the l-Frames received on 
SWP from the UICC 


RQ1, 
RQ2, 
RQ3 


5 


PCD^T 


Acknowledge the received RF frame 





5.9.2 CLT data transmission mode for ISO/IEC 1 4443-3 Type A 
5.9.2.1 CLF processing delay (three subclauses) 



5.9.2.1.1 Conformance requirements 

Reference: TS 102 613 [1], clause 12.2.1. 



RQ1 



The CLF receives data from RF and sends it to the UICC over SWP. 



RQ2 



When receiving from RF, the CLF shall deliver the received RF data block as DATA_FIELD within 
exactly one CLT frame. 

In the case where the incoming RF data block exceeds the length limit of CLT LLC, an error on the RF 
side or wrong RF protocol type shall be assumed and proper error handling shall be executed. 



Reference: TS 102 613 [1], clause 12.2.2. 



RQ3 



The CLF receives data from UICC over SWP and sends it to RF. 



RQ4 



The CLF shall deliver each received SWP data block as exactly one RF data block. 



RQ5 



Within a CLT session, upon reception of a CLT frame, if the CRC is not correct, the CLF shall follow the 
rules given in clause 11.6.2 (TS 102 613 [1]) and in case of non-pipelining, the CLF shall not modulate 
the RF field. 



Reference: TS 102 613 [1], clause 12.2.3. 



RQ6 The total processing delay shall respect T^CLF, delay ^'^ specified in 102 613 [1]. 



Reference: TS 102 613 [1], clause 11.3. 



RQ7 



When sending a frame with the CLT PAYLOAD in Type A aligned structure, meaningless bits in the last 
byte of the CLT PAYLOAD shall be padded with 0. 



Reference: TS 102 613 [1], clause 11.5.1. 



R08 



When the CLF receives a CLT frame with Type A aligned DATA_FIELD, the bit count shall be retrieved 
implicitly from the length of the CLT PAYLOAD, where the interpretation rule is defined as table 1 1 .3 in 
TS102 613[1]. 



RQ9 



When the CLF sends a CLT frame with Type A aligned DATA_FIELD, the size of the CLT PAYLOAD 
shall be determined according to table 1 1 .2 in TS 1 02 61 3 [1 ] and the number of RF bits to be sent. 
When the CLF receives a CLT frame with Type A aligned DATA_FIELD it shall interpret it as an 
instruction to send N full bytes plus N parity bits over the RF where N is determined from the size of the 
DATA_FIELD according to table 1 1 .3, for 1 < N < 25. 



RQ10 



RQ11 



When the CLF receives a CLT frame with a Type A aligned DATA_FIELD of a size of one byte it shall 
interpret it as an instruction to send the least significant 4 bits over the RF. 
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Reference: TS 102 613 [1], clause 11.5.2. 



RQ12 



For ISO/I EC 14443-3 [5] Type A, after the CLF has received an RF frame, a CLT frame with all RF data 
in the DATA_FIELD shall be composed and sent to the UICC except for the first frame after RF 
protocol initialization. 



NOTE 1: Test cases for RQ2, 2"'* part (error situations) are out of scope of the present document. 

NOTE 2: Test cases for RQ5, 2"'* part (reference to clause 1 1.6.2 of TS 102 613 [1]) are given in clause 5.8.7.2 of 
the present document, test cases for the error situations in case of non-pipeling are out of scope of the 
present document. 

5.9.2.1 .2 Test case 1 : CLF processing time - Type A aligned communication, with RF 

response 

Execution of this test case might require the support of an upper layer (e.g. HCI as per TS 102 622 [4]). This 
information shall be provided by the DUT manufacturer. 

The test equipment shall provide a PCD capable to perform ISO/lEC 14443-3 [5] type A RF communication, with RF 
frame reception length of up to 32 bytes. 

5.9.2.1.2.1 Test execution 

The test procedure shall be executed once for each of following parameter sets: 

• Payload length in RF bytes of RF frame sent from PCD to CLF. 

• CLT_PAYLOAD length of CLT frame sent from UICC to CLF. 

• The combination of the two parameter above shall be as follows: 



Combination number 


CLT PAYLOAD 


RF bytes 


1 


29 


1 


2 


21 


4 


3 


16 


10 


4 


9 


15 


5 


5 


18 


6 


2 


24 


7 


1 


25 
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5.9.2.1.2.2 Initial conditions 

• CLT session (ISO/IEC 14443-3 [5] Type A) is established, and no further CLT frame exchange is expected. 

5.9.2.1.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


PCD^T 


Send a RF frames to the terminal 




2 


T^UICC 


Forward the RF data to the UICC by sending "no administrative command" 
CLT frame in Type A aligned format containing the given RF data 


RQ1, 
RQ2, 
RQ6, 
RQ7, 
RQ9, 
RQ12 


3 


UICC->T 


Respond "no administrative command" CLT frame in Type A aligned format 
containing CLT PAYLOAD (see note 2) 


RQ5 


4 


T^PCD 


Send RF frame containing the RF response data to the PCD 


RQ3, 
RQ4, 
RQ5, 
RQ6, 
RQ8, 
RQ10, 
RQ11 


NOTE 1 : There may be overlapping of steps 1 and 2, and of steps 3 and 4. 
NOTE 2: RQ5 shall only be validated in pipelining case. 



5.9.2.1.3 



Test case 2: CLF processing time, no RF response 



Execution of this test case might require the support of an upper layer (e.g. HCl as per TS 102 622 [4]). This 
information shall be provided by the DUT manufacturer. 

The test equipment shall provide a PCD capable to perform ISO/IEC 14443-3 [5] type A RF communication, with RF 
frame reception length of up to 32 bytes. 

5.9.2.1.3.1 Test execution 

The test procedure shall be executed once for each of following parameter sets: 

• There are no test case-specific parameters for this test case. 

5.9.2.1.3.2 Initial conditions 

• CLT session (ISO/IEC 14443-3 [5] Type A) is established, and no further CLT frame exchange is expected. 
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5.9.2.1.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


User 


Trigger the PCD to send a 1^' RF frame with N = 24 bytes of RF data to the 
terminal, and a 2"'' RF frame with N < 25 bytes of RF data immediately after 
delay = (Tclf delay + '-"^^ processing time used in step 4) related to the 1®' 
RF frame has elapsed 
Where Tf^^p^jg, = 210 |js + (15 |js per received byte of RF data) 

See note 2 




2 


T 


Receive 1^' RF frame from PCD 




3 


T ^ UICC 


Forward the the RF data of the 1®' frame to the UICC by means of a CLT 
frame with ADI\/IIN_FIELD set to 0000 


RQ1, 
RQ2, 
RQ6 


4 


UICC 


Simulate the UICC processing time with a value of 150 \is between 
reception of the CLT command and the sending of the CLT response 




5 


UICC^T 


Respond CLT frame with bytes in the CLT PAYLOAD and with 
ADIVIIN FIELD set to 0000 




6 


T 


Send no RF frame to the PCD 




7 


T 


Receive 2"^ RF frame from PCD 




8 


T-»UICC 


Forward the RF data of the 2"^ RF frame to the UICC by means of a CLT 
frame with ADIVIIN FIELD set to 0000 


RQ6 


NOTE 1 : There may be overlapping of steps 2 and 3. 

NOTE 2: The 1^' RF frame is sized to 24 Bytes to be compatible with command sets used in the field, while 
avoiding overly constraining the CLF. 



5.9.2.2 



Timing value for the CLF processing delay (Request Guard Time) 



5.9.2.2.1 



Conformance requirements 



Reference: TS 102 613 [1], clause 12.2.4. 



RQ1 



The CLF shall respect T^^p ^jg, as described in 1 02 61 3 [1 ]. 



RQ2 



If the PCD sends a REOA or WUPA to the CLF during a CLT session, the CLF shall forward the REOA 

or WUPA encapsulated in a CLT frame having a CLT_PAYLOAD length of 1 byte to the UICC. 

The CLF shall properly process a CLT frame with the ADMIN_FIELD CL_GOTO_INIT and no 
DATA_FIELD present. 



RQ3 



Reference: TS 102 613 [1], clause 11.5.2. 



RQ4 



For ISO/IEC 14443-3 [5] Type A, after reception of a CLT frame from the UICC, the CLF shall transmit 
the received data via RF if the CLT frame included a DATAFIELD, if no DATAFIELD was present then 
no data shall be transmitted via RF. 



Reference: TS 102 613 [1], clause 11.5.3.3. 



RQ5 



If the CLF was selected from IDLE state and the CLF receives a ADIVIINFIELD containing 
CL GOTO INIT the CLF shall enter the IDLE state. 



RQ6 



If the CLF was selected from HALT state and the CLF receives a ADI\/IIN_FIELD containing 
CL GOTO INIT the CLF shall enter the HALT state. 



RQ7 



If the CLF receives a ADI\/IIN_FIELD containing CL_GOTO_HALT the CLF shall enter the HALT state. 



RQ8 



After the transition to ISO/IEC 14443-3 [5] "IDLE" or "HALT" state, the CLF shall process 

ISO/IEC 14443-3 [5] Type A RF protocol initialization, and proceed as described in clause 1 1 .5.3.1 in 

TS102 613[1]. 



NOTE: How to test for R08 is FFS. 
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5.9.2.2.2 Test case 1 : CLF processing time, Request Guard Time from IDLE state - Type A 

state transition 

Execution of this test case might require the support of an upper layer (e.g. HCI as per TS 102 622 [4]). This 
information shall be provided by the DUT manufacturer. 

The test equipment shall provide a PCD capable to perform ISO/IEC 14443-3 [5] type A RF communication, with RF 
frame reception length of at least 32 bytes. 

5.9.2.2.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• All RF frames provide REQA command, as per ISO/IEC 14443-3 [5]. 

• All RF frames provide WUPA command, as per ISO/IEC 14443-3 [5]. 

5.9.2.2.2.2 Initial conditions 

• If the SHDLC link is established it shall be idle, i.e. no further communication is expected. 

• The CLF is ready to perform the ISO/IEC 14443-3 [5] Type A protocol initialization. 



5.9.2.2.2.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


PCD ^ ^ T 


Perform the initialization of the RF ISO/IEC 14443-3 [5] Type A protocol 
(with anti-collision and selection) from IDLE state 




2 


PCD^T 


Send RF frame to trigger the CLF to open CLT session 




3 


T^UICC 


Send CLT administrative command 




4 


UICC->T 


Send response 




5 


PCD^T 


Send a 1^' REQAWUPA to the terminal, and prepare to send a 2"^ 
REOA/WUPA after Request Guard Time (ISO/IEC 14443-3 [5]) related to 
the 1st REOA/WUPA has elapsed (see step 9) 




6 


T-^UICC 


Forward the the RF data to the UICC by means of a CLT frame with 
ADMIN FIELD set to 0000 and having a DATA FIELD length of 1 byte 


RQ1, 
RQ2, 


7 


UICC 


Simulate the UICC processing time between reception of the RF data and 
the sending of the response, with a processing time of 215 [xs (see note 2). 
There shall not be more than 1 idle bit after the resume. The 215 [is is 
calculated to ensure that the CLF can respect the Request Guard Time 




8 


UICC^T 


Respond CLT frame with the ADMIN FIELD CL GOTO INITandno 
DATA FIELD present 




9 


T 


Send no RF frame to the PCD (see note 1) 


RQ4, 
RQ5, 
RQ6 


10 


PCD^T 


Send a 2"^ REOA/WUPA after Request Guard Time related to the 1^* 
REOA/WUPA has elapsed 




11 


T^ PCD 


Send RF frame containing the RF response ATOA as per 
ISO/IEC 14443-3 [5] to the PCD 


RQ1, 
RQ3 


12 


PCD ^ ^ T 


Complete the initialization of the RF ISO/IEC 14443-3 [5] Type A protocol 
(with anti-collision and selection) 




13 


PCD^T 


Send RF frame to trigger the CLF to open CLT session 




14 


T^UICC 


Send CLT administrative command 




15 


UICC-^T 


Send response 




NOTE 1 : Action on reception of CL_GOTO_INIT as per TS 102 613 [1]. 

NOTE 2: The UICC processing time is defined as the time between the last data bit received over SWP and and 
the first bit sent over SWP where: 

- The last data bit received over SWP is the end of the last bit of EOF on signal SI . 

- The first bit sent over SWP is the start of the resume on signal S2. 
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5.9.2.2.3 Test case y: CLF processing time, Request Guard Time from HALT state- Type A 

state transition 

Execution of this test case might require the support of an upper layer (e.g. HCI as per TS 102 622 [4]). This 
information shall be provided by the DUT manufacturer. 

The test equipment shall provide a PCD capable to perform ISO/IEC 14443-3 [5] type A RF communication, with RF 
frame reception length of at least 32 bytes. 

5.9.2.2.3.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• none. 

5.9.2.2.3.2 Initial conditions 

• If the SHDLC link is established it shall be idle, i.e. no further communication is expected. 

• The CLF is ready to perform the ISO/IEC 14443-3 [5] Type A protocol initialization. 
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5.9.2.2.3.3 



Test procedure 



Step 


Direction 


Description 


RQ 


1 


PCD ^ ^ T 


Perform the initialization of the RF ISO/IEC 14443-3 [5] Type A protocol 
(with anti-collision and selection) from HALT state 




2 


PCD->T 


Send RF frame to trigger the CLF to open CLT session 




3 


T^UICC 


Send CLT administrative command 




4 


UICC^T 


Send response 




5 


PCD-»T 


Send a 1^' WUPA to the terminal, and prepare to send a 2"^ WUPA after 
Request Guard Time (ISO/IEC 14443-3 [5]) related to the 1^' WUPA has 
elapsed (see step 9) 




6 


T^UICC 


Forward the the RF data to the UICC by means of a CLT frame with 
ADIVIIN FIELD set to 0000 and having a DATA FIELD length of 1 byte 


RQ1, 
RQ2, 


7 


UICC 


Simulate the UICC processing time between reception of the RF data and 
the sending of the response, with a processing time of 215 [xs (see note 2). 
There shall not be more than 1 idle bit after the resume 
The 215 |is is calculated to ensure that the CLF can respect the Request 
Guard Time 




8 


UICC^T 


Respond CLT frame with the ADMIN_FIELD CL_GOTO_INIT and no 
DATA FIELD present 




9 


T 


Send no RF frame to the PCD (see note 1) 


RQ4, 
RQ5, 
RQ6 


10 


PCD^T 


Send a 2"^ wUPA after Request Guard Time related to the l^t WUPA has 
elapsed 




11 


T^ PCD 


Send RF frame containing the RF response ATQA as per 
ISO/IEC 14443-3 [5] to the PCD 


RQ1, 
RQ3 


12 


PCD <- -^ T 


Complete the initialization of the RF ISO/IEC 14443-3 [5] Type A protocol 
(with anti-collision and selection) 




13 


PCD^T 


Send RF frame to trigger the CLF to open CLT session 




14 


T^UICC 


Send CLT administrative command 




15 


UICC-^T 


Send response 




16 


PCD^T 


Send HLTA 




17 


T^UICC 


Send "no administrative command" CLT frame in Type A aligned format 
containing the given RF data 




18 


UICC^T 


Respond CLT frame in Type A aligned format with administrative command 
CL GOTO HALT and without CLT PAYLOAD 




19 


T 


Enter ISO/IEC 14443-3 [5] Type A HALT state 




20 


PCD ^ ^ T 


Verify the HALT state by applying ISO/IEC 14443-3 [5] anticollision 
commands 


RQ7 


NOTE 1 : Action on reception of CL_GOTO_INIT as per TS 102 613 [1]. 

NOTE 2: The UICC processing time is defined as the time between the last data bit received over SWP and and 
the first bit sent over SWP where: 

- The last data bit received over SWP is the end of the last bit of EOF on signal SI . 

- The first bit sent over SWP is the start of the resume on signal S2. 



5.9.3 CLT data transmission mode for ISO/IEC 1 8092 21 2 kbps/424 kbps 
passive mode 

Conformance requirements and test cases for this clause are FFS. 
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Annex A: 
Void 
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Annex B (informative): 

Core specification version information 

Unless otherwise specified, the versions of TS 102 613 [4] from which conformance requirements have been extracted 
are as follows. 



Release 


Latest version from which conformance requirements 
have been extracted 


7 


V7.9.0 + SCP(1 2)0001 67 


8 


V8.2.0 + SCP(1 2)000207 


9 


V9.2.0 + SCP(1 2)000208 
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Annex C (informative): 
Change history 



This annex lists all Changes Requests (CR) applied to the present document. 



Change history 
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CR 


Rev 
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Subject/Comment 
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F 


Modify test case 5. 9.2. 1.2 


SCP(10)0118 


004 


- 


F 
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F 
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F 
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- 


F 
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F 
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F 
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F 
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